जब मैं डीडीडी का पालन करने की कोशिश करता हूं तो क्या मुझे हमेशा सेवाओं के माध्यम से जाना चाहिए?क्या मुझे हमेशा सेवा का उपयोग करना चाहिए, या क्या मैं सीधे भंडार का उपयोग कर सकता हूं?
या क्या मैं डोमेन ऑब्जेक्ट प्राप्त करने के लिए सीधे एक रिपॉजिटरी का उपयोग कर सकता हूं?
व्यक्तिगत रूप से, मुझे नियंत्रकों में रिपॉजिटरीज़ देखना पसंद नहीं है, या सामान्य रूप से प्रस्तुति परत में। लेकिन मैंने इसे कई बार देखा है और डीडीडी के संदर्भ में इसके साथ कुछ भी गलत नहीं है।
मुझे लगता है कि जवाब यह है कि यह इस बात पर निर्भर करता है कि आपकी परियोजना कितनी बड़ी है। अधिक जटिल परियोजनाओं में एक सेवा परत अधिक बार पाई जाती है। जबकि उदाहरण के लिए सरल एमवीसी वेबसाइटें सीधे रिपोजिटरी का उपयोग करें।
या क्या मैं डोमेन ऑब्जेक्ट प्राप्त करने के लिए सीधे एक रिपॉजिटरी का उपयोग कर सकता हूं?
आप निश्चित रूप से कर सकते हैं। यह वास्तव में भंडार का लक्ष्य है। मुझे आश्चर्य है कि आप किस प्रकार की सेवा के लिए अन्यथा इसका उपयोग करेंगे (एसओए या वेब सेवा आधारित वास्तुकला के विशिष्ट संदर्भ को छोड़कर)।
अगर मैं सेवाओं बाईपास और डोमेन संस्थाओं सीधे (एक MVC नियंत्रक में उदाहरण के लिए) खजाने से प्राप्त कर सकते हैं मेरे (इरादा) सवाल था – jgauffin
खैर मैं यह सही हो गया और जवाब है हां :) यह है कि कुछ पूरी तरह से माना जाता है को देखने के लिए मज़ेदार है सामान्य और सामान्य यदि आप मूल डीडीडी पुस्तक और आंदोलन को देखते हैं तो अब लोगों को डर लगता है ... – guillaume31
मुझे डर नहीं है। मैं सिर्फ यह जानना चाहता था कि सबसे अच्छा अभ्यास क्या है। पुस्तक नौ साल पहले जारी किया गया था और वहाँ तब से एक या दो बातें हुआ हो सकता है .. – jgauffin
डीडीडी सिद्धांतों का उपयोग करके संरचित मेरी पहली परियोजना को पूरा करने के बाद: डी, मैंने पाया कि आवेदन परत के लिए उपलब्ध डोमेन सेवाओं और रिपॉजिटरी दोनों के लिए उपयोगी है।
प्रमुख मुद्दा: अनुप्रयोग परत आपको लगता है कि वास्तुकला उपयोग कर रहे हैं अपने वेब सेवाओं में अपने WCF सेवाओं या कोड हो सकता है। यह सब आपके कार्यान्वयन पर निर्भर करता है। यदि यह आपके कार्यान्वयन के अनुरूप है, तो आपकी एप्लिकेशन लेयर आपकी प्रस्तुति परत के समान हो सकती है, इस प्रकार आपके contollers या वेब फ़ॉर्म कोड में एप्लिकेशन लेयर कोड होना चाहिए।
रिपोजिटरीज इन-मेमोरी संग्रह की तरह कार्य करता है। एप्लिकेशन लेयर के लिए, कोड दिखाना चाहिए कि आप किसी पुराने संग्रह का उपयोग कर रहे हैं।
डोमेन सेवा प्रोसेसर या एक्सेसर्स की तरह अधिक जानकारी के लिए काम करती है जो कभी अपडेट नहीं की जाएगी, शायद संसाधित की जाएगी, लेकिन सीधे अपडेट नहीं की जाएगी। एप्लिकेशन परत पर, कोड दिखना चाहिए कि आप किसी भी पुरानी वेब सेवा का उपयोग कर रहे हैं।
कहा जा रहा है, मैं कुछ उदाहरण के साथ और अधिक समझा जाएगा:
डेटा संग्रह स्थान
मेरे खजाने वास्तव में एक कार्यान्वयन वस्तु मेरे द्वारा बनाए गए के साथ आपके द्वारा लिखे गए एक सामान्य संग्रह से विरासत है कि डेटाबेस कुंजी और व्यापार समाहित एक साथ मॉडल। इस दृष्टिकोण का उपयोग करना, मैं अपने इंटरफेस जैसे
BusinessObject this[int index];
में एक इंडेक्सर परिभाषित कर सकते हैं और मैं एक गेटर है कि व्यापार अंतर्निहित संग्रह के सूचकांक और एक सेटर के आधार पर उद्देश्य यह है कि डेटा कुंजी देखने जाएगा वापस आ जाएगी हो सकता है अंतर्निहित संग्रह से और ऑब्जेक्ट को डेटाबेस में सहेजें। यह आवेदन कोड अत्यंत सरल बनाता है उदाहरण के लिए
IBusinessObjectRepository repository = new SqlBusinessObjectRepository(sqlString);
BusinessObject obj = repository[0]; //Get first object in the list.
//Make some changes to the business object by setting properties or calling methods to process business logic.
repository[0] = obj; //Save the object back to the database.
सेवाएं
मैं सेवाओं का उपयोग संस्थाओं और मूल्य की वस्तुओं की सूची है कि मैं व्यक्तिगत रूप से संपादित करने के लिए नहीं जा रहा हूँ पुनः प्राप्त करने और, मेरे मामले में, कर रहे हैं कुल रूट पर विधियों को कॉल करते समय केवल उपलब्ध चयन या मान के रूप में उपयोग किया जाता है।आम तौर पर, मैं इस जानकारी को वेब सर्वर पर कैश करता हूं। डोमेन सेवा के लिए यह एकमात्र उपयोग नहीं है, बस मेरा उदाहरण है। एप्लिकेशन लेयर कोड अभी भी अपेक्षाकृत सरल बना हुआ है।
IBusinessService service = new ImplBusinessService(implementationArgs);
List<BusinessObject> objsToCache = service.GetBusinessObjects();
//cache the objects on the web server.
अंत में और DDD सिद्धांतों की मेरी समझ से, अनुप्रयोग परत या तो सेवाओं या खजाने से व्यापार वस्तुओं का उपयोग करने के लिए सक्षम होना चाहिए। उनके बीच चुनाव डोमेन मॉडल के भीतर सबसे अच्छा फिट बैठता है।
"मैं नियंत्रकों में खजाने देखना पसंद नहीं करते" => तुम क्यों और क्या मध्यवर्ती परत आप नियंत्रक और भंडार के बीच जोड़ा जाने पर विस्तृत कर सकते हैं? – guillaume31
नियंत्रक बहुत जल्दी फूला हुआ होते हैं। इसके कारणों में से एक कारण है क्योंकि देव अपने नियंत्रकों में व्यावसायिक तर्क चिपकते हैं। व्यापार तर्क केवल मुख्य रूप से डोमेन परत में रहना चाहिए, और फिर सेवा परत में - नियंत्रक में नहीं, और भंडार में नहीं। अपने नियंत्रक में एक (एप्लिकेशन) सेवा का उपयोग करके आप इससे बचें। तो उदाहरण के लिए आप accountService.GetUserByEmail (ईमेल), या catalogueService.GetProductViewModel पर कॉल करेंगे। आपका नियंत्रक अच्छा और दुबला रहता है और आपकी एप्लिकेशन सेवा विभिन्न भंडारों से बात करने का समन्वय करती है। – autonomatt
सिर्फ इसलिए कि आपको किसी संग्रह से ऑब्जेक्ट मिलता है, इसका मतलब यह नहीं है कि आप व्यवसाय तर्क में सौदा करते हैं। यह किसी अन्य परत में उपयोग करने के लिए डोमेन परत से * ऑब्जेक्ट को प्राप्त करने के बारे में है। और मैं नहीं देख सकते हैं कि कैसे एक एकल लाइन userRepository.GetUserByEmail (ईमेल) नियंत्रक अधिक bloats accountService.GetUserByEmail (ईमेल) की तुलना में। – guillaume31