नियंत्रक/सेवाएं/डीएओ

Question

के साथ काम करने के लिए कौन सा डिज़ाइन पैटर्न बेहतर है मेरे करियर के दौरान मैंने कुछ अलग डिज़ाइन देखा, डीएओ, सेवा, नियंत्रक परतों के साथ कैसे काम करना है। मैं दो के बारे में पूछना चाहता हूं, जो समान हैं लेकिन कुछ मतभेद हैं। पहला डिजाइन परतों के बीच दृश्य बाधा उत्पन्न करता है। नियंत्रक हमेशा सेवाओं और सेवाओं का उपयोग करते हैं। सेवाएं अन्य सेवाओं या डीएओ का उपयोग कर सकती हैं। नियंत्रक सीधे किसी भी डीएओ का उपयोग नहीं कर सकते हैं। यह डिज़ाइन स्पष्ट है, लेकिन मेरे लिए बड़ा नुकसान है: हमें हमेशा डीएओ में प्रत्येक विधि के लिए सेवा में विधि बनाना है। लेकिन कई मामलों में सेवा विधियां केवल डीएओ विधियों और कुछ और का आह्वान करती हैं।

उदाहरण के लिए: हम UserDao

class UserDao { 
    public List<User> findByName(String name) { ... } 
    public List<User> findByLastName(String name) { ... } 
    public List<User> findOlderThan(int age) { ... } 

    ...... 
} 

उपरोक्त सभी तरीकों नियंत्रकों द्वारा उपयोग किया जाता है। हमें अपने मामले में क्या करना चाहिए? UserService में इसी तरह के तरीकों बनाएँ:

class UserService { 
    public List<User> findByName(String name) { return userDao.findByName(name); } 
    public List<User> findByLastName(String name) { return userDao.findByLastName(name); } 
    public List<User> findOlderThan(int age) { return userDao.findOlderThan(age); } 

    ...... 
} 

मेरे लिए यह केवल पढ़ने के तरीकों के लिए अतिरिक्त अनावश्यक परत है।

दूसरे डिज़ाइन में हमें इसके साथ कोई समस्या नहीं है क्योंकि हम सीधे नियंत्रकों में डीएओ का उपयोग कर सकते हैं। इस डिज़ाइन में हमारे पास एक नियम है: यदि हम "डेटा स्टोर" से डेटा पुनर्प्राप्त करना चाहते हैं तो हम किसी भी परत में डीएओ का उपयोग कर सकते हैं, अगर हम "डेटा स्टोर" में कुछ बदलाव करना चाहते हैं तो हमें सेवा विधियों का उपयोग करना होगा।

इन डिजाइनों के बारे में आप क्या सोचते हैं? कौनसा अच्छा है? मुझे अपनी परियोजनाओं में किस का उपयोग करना चाहिए और जिसे भुलाया जाना चाहिए? क्या आप इस क्षेत्र में अपने अनुभव के साथ साझा कर सकते हैं?

Answer 1

सेवाएं, एमवीसी और एमवीसी-प्रेरित डिजाइन पैटर्न में मॉडल परत के "शीर्ष भाग" हैं। यह प्रेजेंटेशन लेयर डोमेन बिजनेस लॉजिक के साथ कैसे इंटरैक्ट करता है (साथ ही, "रीडिंग" भाग वास्तव में दृश्य उदाहरणों द्वारा किया जाना चाहिए)।

ऐसी संरचना में सेवाएं बाधा के रूप में कार्य करती हैं, जो प्रस्तुति परत को अलग करती है और बाद में मॉडल की आंतरिक संरचना को बदलने में आपको अतिरिक्त स्वतंत्रता देती है।

एक और चीज जो आपको ध्यान में रखना है वह यह है कि वहां अधिक संरचनाएं हैं, तो DAO एस सेवाएं जो बातचीत करती हैं। सबसे पहले domain objects (व्यावसायिक वस्तुओं, मॉडल ऑब्जेक्ट्स) हैं जो एक विशेष इकाई से संबंधित विभिन्न व्यावसायिक नियमों को समाहित करते हैं। फिर आपके पास data mappers भी हो सकता है, जो डीएओ के बजाय भंडारण तर्क को सारणीबद्ध करता है। या डीएओ जो मैपर और डोमेन ऑब्जेक्ट्स के बीच जानकारी का अनुवाद करते हैं। बड़े पैमाने पर आवेदन में unit(s) of work भी होगा। छोटे पैमाने पर आप कुछ active record उदाहरणों के साथ ठीक होंगे।

आप कह सकते हैं कि मॉडल परत में संरचना के तीन मुख्य समूह होते हैं जहां मॉडल के विभिन्न पहलुओं को कार्यान्वित करते हैं: डोमेन, स्टोरेज और एप्लिकेशन तर्क।

एप्लिकेशन तर्क स्टोरेज संरचनाओं डोमेन ऑब्जेक्ट्स के बीच बातचीत है। यही वह सेवाएं है जिसके लिए सेवाएं जिम्मेदार हैं।

यदि आप डीएओ का पर्दाफाश करते हैं, तो आपकी मॉडल परत प्रस्तुति में रिसाव शुरू होती है। नियंत्रक को इस बारे में कोई जानकारी नहीं होनी चाहिए कि संरचनाओं का उपयोग किस प्रकार किया जाता है, और जब वे बने रहते हैं।