क्या सेवाओं को हमेशा डीटीओ वापस करना चाहिए, या क्या वे डोमेन मॉडल भी लौटा सकते हैं?


174

मैं (पुनः) बड़े पैमाने पर डिज़ाइन तैयार कर रहा हूं, हम DDD के आधार पर मल्टी-लेयर आर्किटेक्चर का उपयोग करते हैं।

हमारे पास डेटा लेयर (रिपॉजिटरी के कार्यान्वयन), डोमेन लेयर (डोमेन मॉडल की परिभाषा और इंटरफेस - रिपॉजिटरी, सर्विसेज, कार्य की इकाई), सर्विस लेयर (सेवाओं के कार्यान्वयन) के साथ MVC है। अब तक, हम सभी परतों के पार डोमेन मॉडल (ज्यादातर इकाइयाँ) का उपयोग करते हैं, और हम डीटीओ का उपयोग केवल दृश्य मॉडल (नियंत्रक, सेवा रिटर्न डोमेन मॉडल) के रूप में करते हैं और नियंत्रक व्यू मॉडल बनाता है, जिसे दृश्य में पास किया जाता है)।

मैं प्रयोग कर रहा हूँ, उपयोग नहीं, मानचित्रण और DTO गुजर के बारे में अनगिनत लेख पढ़ा। मैं समझता हूं कि इसका कोई निश्चित जवाब नहीं है, लेकिन मुझे यकीन नहीं है कि यह ठीक है या सेवाओं से नियंत्रकों के लिए डोमेन मॉडल वापस नहीं कर रहा है। यदि मैं डोमेन मॉडल वापस करता हूं, तो यह अभी भी दृश्य में पारित नहीं हुआ है, क्योंकि नियंत्रक हमेशा दृश्य-विशिष्ट दृश्य मॉडल बनाता है - इस मामले में, यह वैध लगता है। दूसरी ओर, यह तब सही नहीं लगता जब डोमेन मॉडल बिजनेस लेयर (सर्विस लेयर) छोड़ देता है। कभी-कभी सेवा को डेटा ऑब्जेक्ट को वापस करने की आवश्यकता होती है जिसे डोमेन में परिभाषित नहीं किया गया था और फिर हमें या तो डोमेन में नया ऑब्जेक्ट जोड़ना होगा जो मैप नहीं किया गया है, या पीओसीओ ऑब्जेक्ट बनाएं (यह बदसूरत है, क्योंकि कुछ सेवाएं डोमेन मॉडल वापस करती हैं, कुछ प्रभावी रूप से डीटीओ)।

प्रश्न है - अगर हम कड़ाई से दृश्य मॉडल का उपयोग करते हैं, तो क्या डोमेन मॉडल को नियंत्रकों के लिए सभी तरह से वापस करना ठीक है, या हमें सेवा परत के साथ संचार के लिए हमेशा डीटीओ का उपयोग करना चाहिए? यदि हां, तो क्या सेवाओं की आवश्यकता के आधार पर डोमेन मॉडल को समायोजित करना ठीक है? (स्पष्ट रूप से मुझे ऐसा नहीं लगता है, क्योंकि सेवाओं को किस डोमेन का उपभोग करना चाहिए।) यदि हमें डीटीओ से सख्ती से चिपके रहना चाहिए, तो क्या उन्हें सेवा परत में परिभाषित किया जाना चाहिए? (मुझे ऐसा लगता है।) कभी-कभी यह स्पष्ट होता है कि हमें डीटीओ का उपयोग करना चाहिए (उदाहरण के लिए, जब सेवा बहुत सारे व्यापार तर्क देती है और नई वस्तुएं बनाती है), कभी-कभी यह स्पष्ट होता है कि हमें केवल डोमेन मॉडल का उपयोग करना चाहिए (उदाहरण के लिए, जब सदस्यता सेवा एनीमिक उपयोगकर्ता वापस आती है। एस) - ऐसा लगता है कि यह डीटीओ बनाने के लिए बहुत अधिक समझ में नहीं आएगा जो डोमेन मॉडल के समान है) - लेकिन मैं संगतता और अच्छे अभ्यासों को पसंद करता हूं।

आलेख डोमेन बनाम डीटीओ बनाम व्यूमॉडल - उनका उपयोग कैसे और कब करें? (और कुछ अन्य लेख भी) मेरी समस्या से बहुत मिलते-जुलते हैं, लेकिन यह इस सवाल का जवाब नहीं देता है। अनुच्छेद मैं एफई के साथ भंडार पैटर्न में DTOs को लागू करना चाहिए? यह भी समान है, लेकिन यह DDD के साथ सौदा नहीं करता है।

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

हमेशा की तरह, धन्यवाद।


28
उन लोगों के लिए जो करीबी के लिए वोट करते हैं - क्या आप यह समझाने की परवाह करेंगे कि आप इस प्रश्न को राय आधारित क्यों बनाना चाहते हैं?
रॉबर्ट गोल्डवेइन

20
@Aron "कोड समीक्षा उन परियोजनाओं से कोड साझा करने के लिए एक प्रश्न और उत्तर साइट है जो आप सहकर्मी समीक्षा के लिए काम कर रहे हैं।" - मेरा सवाल कोड के बारे में बिल्कुल नहीं है, इसलिए यह विषय से हटकर होगा; SO: "आपके द्वारा सामना की गई वास्तविक समस्या के बारे में प्रश्नों पर ध्यान केंद्रित करें। आपके द्वारा किए गए प्रयासों के बारे में विवरण शामिल करें और वास्तव में आप क्या करने की कोशिश कर रहे हैं।" - मुझे विशिष्ट विशेषज्ञ समस्या है, जिसे मैंने हल करने की कोशिश की। क्या आप अधिक विशिष्ट हो सकते हैं, इस प्रश्न में क्या गलत है, क्योंकि यहां कई प्रश्न वास्तुकला के बारे में हैं और ऐसे प्रश्न स्पष्ट रूप से ठीक हैं, इसलिए मैं किसी और गलतफहमी से बच सकता हूं?
रॉबर्ट गोल्डवेइन

7
उस सवाल को पूछने के लिए धन्यवाद। आपने मुझ पर एक उपकार किया, और मेरे जीवन को बहुत सरल और खुशहाल बनाया, धन्यवाद।
लोआ

9
@RobertGoldwein, SO SO माफिया को बुरा मत मानना, आपका सवाल वैध है।
hyankov

3
इस सवाल को पूछने के लिए बड़ा धन्यवाद
सलमान

जवाबों:


177

जब डोमेन मॉडल बिजनेस लेयर (सर्विस लेयर) छोड़ता है तो यह सही नहीं लगता

आपको लगता है जैसे आप हिम्मत से बाहर खींच रहे हैं? मार्टिन फाउलर के अनुसार: सर्विस लेयर एप्लिकेशन की सीमा को परिभाषित करता है, यह डोमेन को एन्क्रिप्ट करता है। दूसरे शब्दों में यह डोमेन की सुरक्षा करता है।

कभी-कभी सेवा को डोमेन में परिभाषित डेटा ऑब्जेक्ट को वापस करने की आवश्यकता होती है

क्या आप इस डेटा ऑब्जेक्ट का एक उदाहरण प्रदान कर सकते हैं?

अगर हमें सख्ती से डीटीओ से चिपके रहना चाहिए, तो क्या उन्हें सर्विस लेयर में परिभाषित किया जाना चाहिए?

हां, क्योंकि प्रतिक्रिया आपकी सेवा परत का हिस्सा है। यदि इसे "कहीं और" परिभाषित किया गया है, तो सेवा की परत को "कहीं और" संदर्भ देने की आवश्यकता है, जो आपके लेस्गना में एक नई परत जोड़ रहा है।

क्या डोमेन मॉडल को नियंत्रकों के लिए सभी तरह से वापस करना ठीक है, या हमें सेवा परत के साथ संचार के लिए हमेशा डीटीओ का उपयोग करना चाहिए?

एक डीटीओ एक प्रतिक्रिया / अनुरोध वस्तु है, अगर आप इसे संचार के लिए उपयोग करते हैं तो यह समझ में आता है। यदि आप अपनी प्रस्तुति परत (MVC-नियंत्रकों / दृश्य, WebForms, ConsoleApp) में डोमेन मॉडल का उपयोग करते हैं, तो प्रस्तुति परत को आपके डोमेन से कसकर जोड़ा जाता है, डोमेन में किसी भी बदलाव के लिए आपको अपने नियंत्रकों को बदलने की आवश्यकता होती है।

ऐसा लगता है कि यह डीटीओ बनाने के लिए बहुत मायने नहीं रखेगा जो डोमेन मॉडल के समान है)

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

डीटीओ आपके आवेदन में अतिरिक्त जटिलता जोड़ सकता है, लेकिन आपकी परतें हैं। डीटीओ आपके सिस्टम की एक महंगी विशेषता है, वे मुफ्त नहीं आते हैं।

डीटीओ का उपयोग क्यों करें

यह लेख DTO, http://guntherpopp.blogspot.com/2010/09/to-dto-or-not-to-dto.html का उपयोग करके लाभ और हानि दोनों प्रदान करता है

सारांश इस प्रकार है:

कब इस्तेमाल करें

  • बड़ी परियोजनाओं के लिए।
  • परियोजना का जीवनकाल 10 वर्ष और उससे अधिक है।
  • सामरिक, मिशन महत्वपूर्ण आवेदन।
  • बड़ी टीमें (5 से अधिक)
  • भौगोलिक रूप से डेवलपर्स को वितरित किया जाता है।
  • डोमेन और प्रस्तुति अलग हैं।
  • ओवरहेड डेटा एक्सचेंज (डीटीओ का मूल उद्देश्य) कम करें

जब उपयोग करने के लिए नहीं

  • लघु से मध्यम आकार की परियोजना (अधिकतम 5 सदस्य)
  • परियोजना का जीवनकाल 2 वर्ष या उससे अधिक है।
  • GUI, बैकएंड आदि के लिए कोई अलग टीम नहीं।

डीटीओ के खिलाफ तर्क

डीटीओ के साथ तर्क

  • डीटीओ के बिना, प्रस्तुति और डोमेन को कसकर युग्मित किया जाता है। (यह छोटी परियोजनाओं के लिए ठीक है।)
  • इंटरफ़ेस / एपीआई स्थिरता
  • केवल उन विशेषताओं वाले केवल एक DTO को लौटाकर प्रस्तुति परत के लिए अनुकूलन प्रदान कर सकते हैं जो बिल्कुल आवश्यक हैं। लाइनक-प्रोजेक्शन का उपयोग करना , आपको पूरी इकाई को खींचने की जरूरत नहीं है।
  • विकास लागत को कम करने के लिए, कोड बनाने वाले उपकरणों का उपयोग करें

3
नमस्ते, आपके उत्तर के लिए धन्यवाद, यह वास्तव में अच्छा सारांश है, और लिंक के लिए भी धन्यवाद। मेरा वाक्य "कभी-कभी सेवा को डेटा ऑब्जेक्ट को वापस करने की आवश्यकता होती है जिसे डोमेन में परिभाषित नहीं किया गया था" बुरी तरह से चुना गया था, इसका मतलब है कि सेवा एक रिपॉजिटरी (जैसे, गुण) से कई डीओ को जोड़ती है और इन विशेषताओं की एक संरचना के रूप में एक पीओसीओ का उत्पादन करती है (आधारित है) व्यापार तर्क पर)। फिर, वास्तव में अच्छा जवाब के लिए धन्यवाद।
रॉबर्ट गोल्डवेइन

1
एक महत्वपूर्ण प्रदर्शन विचार सिर्फ यह है कि उन डोमेन मॉडल या डीटीओ को आपकी सेवा से कैसे लौटाया जाता है। EF के साथ, यदि आपको डोमेन मॉडल (.ToArray () या ToList (), उदाहरण के लिए) का एक ठोस संग्रह वापस करने के लिए एक क्वेरी का एहसास होता है, तो आप सभी स्तंभों का चयन करके महसूस की गई वस्तुओं को पॉप्युलेट करते हैं। यदि आप इसके बजाय क्वेरी में DTO प्रोजेक्ट करते हैं, तो EF आपके DTO को पॉप्युलेट करने के लिए केवल आवश्यक कॉलम चुनने के लिए पर्याप्त स्मार्ट है, जो कुछ मामलों में स्थानांतरित करने के लिए काफी कम डेटा हो सकता है।
नाक से शब्द निकालना

10
आप अपनी वस्तुओं को 'हाथ से' मैप कर सकते हैं। मुझे पता है, सामान उबाऊ, लेकिन प्रति मॉडल 2-3 मिनट लगते हैं और जब आप बहुत अधिक प्रतिबिंब (ऑटोमैपर इत्यादि) का उपयोग करते हैं तो बहुत सारी समस्याएं लाने की संभावना होती है
रज़वान डुमित्रु

1
इतनी आसानी से और ऐसी सामग्री के साथ जवाब देने के लिए धन्यवाद। आपने मुझ पर एक उपकार किया, और मेरे जीवन को बहुत सरल और खुशहाल बनाया, धन्यवाद।
लोआ

1
हमारे पास 10 मिलियन का प्रोजेक्ट रद्द हो गया था क्योंकि इसे धीमा करना था ... यह धीमा क्यों था? Refelection का उपयोग करके सभी जगह डीटीओ ऑब्जेक्ट को स्थानांतरित करना। सावधान रहे। ऑटोमेपर भी प्रतिबिंब का उपयोग करता है।
रेवेल्वेस

11

ऐसा लगता है कि आपका आवेदन काफी बड़ा और जटिल है क्योंकि आपने डीडीडी के दृष्टिकोण से गुजरने का फैसला किया है। अपने पोको संस्थाओं को या तथाकथित डोमेन संस्थाओं को वापस न करें और आप की सेवा की परत में वस्तुओं को महत्व दें। अगर आप ऐसा करना चाहते हैं तो अपनी सर्विस लेयर को डिलीट कर दें क्योंकि आपको इसकी कोई आवश्यकता नहीं है! मॉडल या डेटा ट्रांसफर ऑब्जेक्ट्स को सर्विस लेयर में रहना चाहिए क्योंकि उन्हें डोमेन मॉडल मेंबर्स को मैप करना चाहिए और इसके विपरीत। तो आपको डीटीओ की आवश्यकता क्यों है? बहुत सारे परिदृश्यों के साथ जटिल अनुप्रयोग में आपको डोमेन की चिंताओं को अलग करना चाहिए और आपको विचारों को प्रस्तुत करना चाहिए, एक डोमेन मॉडल को कई डीटीओ में विभाजित किया जा सकता है और साथ ही कई डोमेन मॉडल को डीटीओ में विभाजित किया जा सकता है। तो अपने DTO को स्तरित वास्तुकला में बनाना बेहतर है यहां तक ​​कि यह आपके मॉडल के समान होगा।

क्या हमें सेवा परत के साथ संचार के लिए हमेशा डीटीओ का उपयोग करना चाहिए? हां, आपको अपनी सेवा परत द्वारा डीटीओ को वापस करना होगा क्योंकि आपने डोमेन मॉडल के सदस्यों के साथ सेवा परत में अपनी रिपॉजिटरी से बात की है और उन्हें डीटीओ को मैप करके एमवीसी नियंत्रक और इसके विपरीत पर लौटना है।

क्या सेवाओं की आवश्यकता के आधार पर डोमेन मॉडल को समायोजित करना ठीक है? एक सेवा केवल रिपॉजिटरी और डोमेन के तरीकों और डोमेन सेवाओं के लिए बात करती है, आपको अपनी आवश्यकताओं के आधार पर अपने डोमेन में व्यवसाय को हल करना चाहिए और डोमेन को यह बताना सेवा कार्य नहीं है कि क्या आवश्यक है।

अगर हमें सख्ती से डीटीओ से चिपके रहना चाहिए, तो क्या उन्हें सर्विस लेयर में परिभाषित किया जाना चाहिए? हां बाद में सेवा में डीटीओ या व्यूमॉडल रखने की कोशिश करें क्योंकि उन्हें सेवा परत में डोमेन सदस्यों के लिए मैप किया जाना चाहिए और अपने आवेदन के नियंत्रकों में डीटीओ को रखने के लिए एक अच्छा विचार नहीं है ( अपनी सेवा परत में अनुरोध रिस्पांस पैटर्न का उपयोग करने की कोशिश करें ), चीयर्स !


1
उसके लिए माफ़ करना! आप इसे यहाँ देख सकते हैं ehsanghanbari.com/blog/Post/7/…
एहसान

10

मेरे अनुभव में आपको वही करना चाहिए जो व्यावहारिक हो। "सबसे अच्छा डिजाइन सबसे सरल डिजाइन है जो काम करता है" - आइंस्टीन। इसके साथ ही मन है ...

यदि हम कड़ाई से दृश्य मॉडल का उपयोग करते हैं, तो क्या डोमेन मॉडल को नियंत्रकों के लिए सभी तरह से वापस करना ठीक है, या क्या हमें सेवा स्तर पर संचार के लिए हमेशा डीटीओ का उपयोग करना चाहिए?

बिलकुल ठीक है! यदि आपके पास डोमेन एंटिटीज, डीटीओ और व्यू मॉडल्स हैं तो डेटाबेस टेबल्स सहित आपके पास 4 स्थानों में दोहराए गए एप्लिकेशन के सभी फ़ील्ड हैं। मैंने बड़े प्रोजेक्ट्स पर काम किया है जहाँ डोमेन एंटिटीज़ और व्यू मॉडल्स ने ठीक काम किया है। इसका एकमात्र अपवाद यह है कि यदि एप्लिकेशन वितरित किया गया है और सेवा परत किसी अन्य सर्वर पर रहता है जिस स्थिति में डीटीओ को क्रमिक कारणों से तार के पार भेजने की आवश्यकता होती है।

यदि हां, तो क्या सेवाओं की आवश्यकता के आधार पर डोमेन मॉडल को समायोजित करना ठीक है? (स्पष्ट रूप से मुझे ऐसा नहीं लगता है, क्योंकि सेवाओं को उस डोमेन का उपभोग करना चाहिए।)

आम तौर पर मैं सहमत होता हूं और नहीं कहूंगा क्योंकि डोमेन मॉडल आमतौर पर व्यापार तर्क का प्रतिबिंब है और आमतौर पर उस तर्क के उपभोक्ता द्वारा आकार नहीं मिलता है।

अगर हमें सख्ती से डीटीओ से चिपके रहना चाहिए, तो क्या उन्हें सर्विस लेयर में परिभाषित किया जाना चाहिए? (मुझे ऐसा लगता है।)

यदि आप उनका उपयोग करने का निर्णय लेते हैं तो मैं सहमत हो जाऊंगा और हां कह दूंगा कि सेवा स्तर सही जगह है क्योंकि यह दिन के अंत में डीटीओ को वापस कर रहा है।

सौभाग्य!


8

मुझे इस पार्टी के लिए देर हो रही है, लेकिन यह इतना सामान्य और महत्वपूर्ण है, सवाल है कि मैंने जवाब देने के लिए मजबूर महसूस किया।

"सेवाओं" से क्या आपका मतलब इवान की नीली किताब में वर्णित "एप्लीकेशन लेयर" से है ? मैं आपको यह मानकर चलता हूँ कि किस मामले में उत्तर यह है कि उन्हें DTO नहीं लौटाना चाहिए । मैं नीली किताब में अध्याय 4 को पढ़ने का सुझाव देता हूं, जिसका शीर्षक है "डोमेन को अलग करना"।

उस अध्याय में, इवांस परतों के बारे में निम्नलिखित कहते हैं:

विभाजन एक जटिल कार्यक्रम परतों में। प्रत्येक परत के भीतर एक डिजाइन विकसित करना जो कि एकजुट है और जो केवल नीचे की परतों पर निर्भर करता है।

इसके लिए एक अच्छा कारण है। यदि आप सॉफ़्टवेयर जटिलता की माप के रूप में आंशिक आदेश की अवधारणा का उपयोग करते हैं तो एक परत के ऊपर एक परत पर निर्भर होने से जटिलता बढ़ जाती है, जो स्थिरता को कम कर देता है।

अपने प्रश्न पर इसे लागू करना, डीटीओ वास्तव में एक एडेप्टर है जो उपयोगकर्ता इंटरफ़ेस / प्रस्तुति परत की चिंता है। याद रखें कि दूरस्थ / क्रॉस-प्रोसेस संचार वास्तव में एक DTO का उद्देश्य है (यह ध्यान देने योग्य है कि उस पोस्ट में Fowler DTO के एक सेवा स्तर का हिस्सा होने के खिलाफ भी तर्क देता है, हालांकि वह जरूरी नहीं कि DDD भाषा में बात कर रहा है)।

यदि आपकी एप्लिकेशन परत उन DTO पर निर्भर करती है, तो यह स्वयं के ऊपर की परत पर निर्भर करता है और आपकी जटिलता बढ़ जाती है। मैं गारंटी दे सकता हूं कि इससे आपके सॉफ़्टवेयर को बनाए रखने की कठिनाई बढ़ जाएगी।

उदाहरण के लिए, क्या होगा यदि आपका सिस्टम कई अन्य प्रणालियों या क्लाइंट प्रकारों के साथ इंटरफेस करता है, प्रत्येक को अपने स्वयं के डीटीओ की आवश्यकता होती है? आप कैसे जानते हैं कि किस डीटीओ को आपकी एप्लिकेशन सेवा का एक तरीका लौटना चाहिए? अगर आप अपनी पसंद की भाषा रिटर्न प्रकार के आधार पर किसी विधि (सेवा विधि, इस मामले में) को ओवरलोडिंग की अनुमति नहीं देते हैं, तो आप उस समस्या को भी कैसे हल करेंगे? और यहां तक ​​कि अगर आप एक तरह से पता लगाते हैं, तो एक प्रस्तुति परत चिंता का समर्थन करने के लिए अपने आवेदन परत का उल्लंघन क्यों करें?

व्यावहारिक रूप से, यह एक सड़क के नीचे एक कदम है जो एक स्पेगेटी वास्तुकला में समाप्त हो जाएगा। मैंने अपने अनुभव में इस प्रकार के विचलन और इसके परिणाम देखे हैं।

जहां मैं वर्तमान में काम करता हूं, हमारे एप्लीकेशन लेयर में डोमेन ऑब्जेक्ट्स की सेवाएं। हम इस समस्या पर विचार नहीं करते हैं क्योंकि इंटरफ़ेस (यानी UI / प्रस्तुति) परत डोमेन परत पर निर्भर करता है, जो इसके नीचे है। इसके अलावा, इस निर्भरता को "संदर्भ केवल" प्रकार की निर्भरता के कारण कम से कम किया जाता है:

a) इंटरफ़ेस लेयर केवल इन डोमेन ऑब्जेक्ट्स को एक्सेस करने में सक्षम है क्योंकि एप्लिकेशन लेयर पर कॉल द्वारा प्राप्त रीड-ओनली रिटर्न वैल्यू है

b) एप्लीकेशन लेयर में सेवाओं के तरीके इनपुट के रूप में केवल "रॉ" इनपुट (डेटा मान) या ऑब्जेक्ट पैरामीटर (पैरामीटर की गिनती को कम करने के लिए जहां आवश्यक हो) को उस लेयर में परिभाषित के रूप में स्वीकार करते हैं। विशेष रूप से, अनुप्रयोग सेवाएँ इनपुट के रूप में डोमेन ऑब्जेक्ट को कभी स्वीकार नहीं करती हैं

इंटरफ़ेस लेयर डोमेन लेयर्स से DTO तक मैप करने के लिए खुद इंटरफेस लेयर के भीतर परिभाषित मैपिंग तकनीकों का उपयोग करता है। फिर से, यह डीटीओ को इंटरफ़ेस लेयर द्वारा नियंत्रित किए जाने वाले एडेप्टर होने पर ध्यान केंद्रित रखता है।


1
त्वरित प्रश्न। मैं वर्तमान में अपनी एप्लिकेशन परत से वापस लौटने के लिए कताई कर रहा हूं। एप्लिकेशन परत से डोमेन एंटाइटिस लौटना गलत लगता है। क्या मैं वास्तव में "बाहर" डोमेन को लीक करना चाहता हूं? इसलिए मैं एप्लिकेशन लेयर से डीटीओ पर विचार कर रहा था। लेकिन वह एक और मॉडल जोड़ता है। आपने अपनी प्रतिक्रिया में कहा कि आप डोमेन मॉडल को "केवल पढ़ने के लिए वापसी मान" के रूप में लौटाते हैं। आप उसे कैसे करते हैं? यानी, आप उन्हें केवल पढ़ने के लिए कैसे बनाते हैं?
माइकल एंड्रयूज

मुझे लगता है कि मैं सिर्फ आपकी स्थिति को अपनाने जा रहा हूं। अनुप्रयोग सेवाएँ डोमेन मॉडल लौटाती हैं। पोर्ट अडैप्टर लेयर्स (REST, प्रेजेंटेशन इत्यादि) फिर उन्हें अपने स्वयं के मॉडल (देखें मॉडल या अभ्यावेदन) में अनुवाद करते हैं। अनुप्रयोग और पोर्ट एडाप्टर के बीच एक DTO मॉडल जोड़ना ओवरकिल लगता है। रिटर्निंग डोमेन मॉडल अभी भी डीआईपी का पालन करता है, और डोमेन लॉजिक बाउंडेड संदर्भ के अंदर रहता है (जरूरी नहीं कि एप्लिकेशन सीमा के अंदर हो। लेकिन यह एक अच्छा समझौता जैसा लगता है)।
माइकल एंड्रयूज

@MichaelAndrews, यह सुनकर खुशी हुई कि मेरे जवाब से मदद मिली। पुन: आपके द्वारा केवल पढ़ी जा रही वस्तुओं के बारे में आपका प्रश्न, वस्तुएं वास्तव में केवल-पढ़ने योग्य (यानी अपरिवर्तनीय) नहीं हैं। मेरा मतलब है कि यह व्यवहार में नहीं होता है (कम से कम मेरे अनुभव में)। एक डोमेन ऑब्जेक्ट को अपडेट करने के लिए इंटरफ़ेस लेयर को या तो ए) डोमेन ऑब्जेक्ट की रिपॉजिटरी का संदर्भ देना होगा, या बी) एप्लिकेशन लेयर में वापस कॉल करें, जो इसे प्राप्त ऑब्जेक्ट को अपडेट करने के लिए। इनमें से कोई भी अच्छे डीडीडी अभ्यास के ऐसे स्पष्ट उल्लंघन हैं जो मुझे लगता है कि वे आत्म-प्रवर्तित हैं। यदि आप परवाह करते हैं तो उत्तर को बेझिझक उठाएं।
BitMask777

यह उत्तर कई कारणों से मेरे लिए बहुत सहज है। सबसे पहले, हम कई यूआई (एपीआई, कंट्रोलर्स) के लिए एक ही एप्लीकेशन लेयर का पुन: उपयोग कर सकते हैं और जैसा कि वे फिट होते हैं, हर एक मॉडल को बदल सकता है। दूसरा, अगर हम ऐप में मॉडल-टू-डीटीओ को बदलना चाहते थे। परत, इसका मतलब है कि डीटीओ ऐप में परिभाषित है। परत, जिसका अर्थ है कि डीटीओ अब हमारे बाउंडेड कॉनटेक्स्ट का हिस्सा है (जरूरी नहीं कि डोमेन!) - यह सिर्फ गलत लगता है।
Robotron

1
मैं आपसे केवल एक अनुवर्ती प्रश्न पूछने वाला था और फिर देखा कि आपने पहले ही इसका उत्तर दे दिया था: "अनुप्रयोग सेवाएँ कभी भी डोमेन ऑब्जेक्ट्स को इनपुट के रूप में स्वीकार नहीं करती हैं"। अगर मैं कर सकता तो मैं फिर से +1 करता।
Robotron

5

पार्टी के लिए देर से, लेकिन मैं ठीक उसी प्रकार की वास्तुकला का सामना कर रहा हूं और मैं "केवल सेवा से डीटीओ" की ओर झुक रहा हूं। यह मुख्य रूप से है क्योंकि मैंने ऑब्जेक्ट के भीतर वैधता बनाए रखने के लिए केवल डोमेन ऑब्जेक्ट्स / एग्रीगेट्स का उपयोग करने का निर्णय लिया है, इस प्रकार केवल अपडेट करते समय, बनाते या हटाते समय। जब हम डेटा के लिए क्वेरी कर रहे होते हैं, तो हम केवल EF को एक रिपॉजिटरी के रूप में उपयोग करते हैं और परिणाम को DTOs में मैप करते हैं। यह हमें पढ़ने के प्रश्नों का अनुकूलन करने और व्यावसायिक वस्तुओं के लिए उन्हें अनुकूलित करने के लिए स्वतंत्र बनाता है, अक्सर डेटाबेस कार्यों का उपयोग करते हुए जैसे वे तेज़ होते हैं।

प्रत्येक सेवा पद्धति अपने स्वयं के अनुबंध को परिभाषित करती है और इसलिए समय के साथ बनाए रखना आसान होता है। मुझे उम्मीद है।


1
वर्षों के बाद हम उसी नतीजे पर पहुँचे, बिलकुल उन कारणों के लिए जिनका आपने यहाँ उल्लेख किया है।
रॉबर्ट गोल्डवेई

@RobertGoldwein यह बहुत अच्छा है! मैं अब अपने फैसले में अधिक आत्मविश्वास महसूस करता हूं। :-)
निकलस वुल्फ

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

1
@ रोबॉट्रोन हमारे पास वेब एपीआई नहीं है, हम एमवीसी का उपयोग करते हैं। तो हां, हम dto को मैप करते हैं: अलग-अलग व्यू मॉडल में। अक्सर एक दृश्य मॉडल में वेब पेज प्रदर्शित करने के लिए बहुत सारे अन्य सामान होते हैं, इसलिए डेटा से डेटा: केवल व्यू मॉडल का एक हिस्सा बनाते हैं
निकल्स वुल्फ

4

अब तक, हम सभी परतों में डोमेन मॉडल (अधिकतर निकाय) का उपयोग करते हैं, और हम डीटीओ का उपयोग केवल दृश्य मॉडल (नियंत्रक, सेवा रिटर्न डोमेन मॉडल) के रूप में करते हैं और नियंत्रक व्यू मॉडल बनाता है, जिसे दृश्य में पास किया जाता है)।

चूंकि डोमेन मॉडल आपके संपूर्ण अनुप्रयोग के लिए शब्दावली ( सर्वव्यापी भाषा ) प्रदान करता है, इसलिए डोमेन मॉडल का व्यापक रूप से उपयोग करना बेहतर है।

ViewModels / DTOs का उपयोग करने का एकमात्र कारण आपके आवेदन में MVC पैटर्न का कार्यान्वयन है View(किसी भी प्रकार की प्रस्तुति परत) और Model(डोमेन मॉडल) को अलग करना। इस स्थिति में आपकी प्रस्तुति और डोमेन मॉडल शिथिल रूप से युग्मित हैं।

कभी-कभी सेवा को डोमेन में परिभाषित डेटा ऑब्जेक्ट को वापस करने की आवश्यकता होती है और फिर हमें या तो डोमेन में नई ऑब्जेक्ट को जोड़ना पड़ता है जो मैप नहीं किया जाता है, या POCO ऑब्जेक्ट बनाता है (यह बदसूरत है, क्योंकि कुछ सेवाएं डोमेन मॉडल वापस करती हैं, कुछ प्रभावी ढंग से डीटीओ)।

मुझे लगता है कि आप अनुप्रयोग / व्यवसाय / डोमेन लॉजिक सेवाओं के बारे में बात करते हैं।

मेरा सुझाव है कि जब आप कर सकते हैं तो आप डोमेन संस्थाएं लौटा दें। यदि अतिरिक्त जानकारी को वापस करने की आवश्यकता है, तो कई डोमेन संस्थाओं को रखने वाले DTO को वापस करने के लिए स्वीकार्य है।

कभी-कभी, वे लोग जो 3 पार्ट फ्रेमवर्क का उपयोग करते हैं, जो डोमेन एंटिटीज़ पर प्रॉक्सी उत्पन्न करते हैं, अपनी सेवाओं से डोमेन एंटिटीज़ को उजागर करने में कठिनाइयों का सामना करते हैं, लेकिन यह केवल गलत उपयोग की बात है।

प्रश्न है - अगर हम कड़ाई से दृश्य मॉडल का उपयोग करते हैं, तो क्या डोमेन मॉडल को नियंत्रकों के लिए सभी तरह से वापस करना ठीक है, या हमें सेवा परत के साथ संचार के लिए हमेशा डीटीओ का उपयोग करना चाहिए?

मैं कहूंगा कि 99,9% मामलों में डोमेन संस्थाओं को वापस करना पर्याप्त है।

डीटीओ के निर्माण को आसान बनाने के लिए और अपने डोमेन संस्थाओं को मैप करने के लिए आप उनमें से ऑटोमैपर का उपयोग कर सकते हैं ।


4

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

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


2

मैं आपको इन दो प्रश्नों का विश्लेषण करने का सुझाव दूंगा:

  1. क्या आपकी ऊपरी परतें (यानी मॉडल / नियंत्रक को देखने और देखने के लिए) डोमेन परत को अलग तरीके से डेटा का उपभोग करती हैं? यदि बहुत अधिक मैपिंग की जा रही है या तर्क भी शामिल है, तो मैं आपके डिज़ाइन को फिर से बनाने का सुझाव दूंगा: यह संभवतः डेटा के वास्तव में उपयोग किए जाने के करीब होना चाहिए।

  2. यह कितनी संभावना है कि आप अपनी ऊपरी परतों को गहराई से बदलते हैं? (उदाहरण के लिए WP.NET के लिए ASP.NET स्वैपिंग)। यदि यह विपरीत है और आपकी वास्तुकला बहुत जटिल नहीं है, तो आप जितना हो सके उतने डोमेन संस्थाओं को उजागर करने से बेहतर हो सकते हैं।

मुझे डर है कि यह काफी व्यापक विषय है और यह वास्तव में आपके सिस्टम और इसकी आवश्यकताओं के लिए कितना जटिल है।


हमारे मामले में, ऊपरी परत निश्चित रूप से नहीं बदलेगी। कुछ मामलों में, सेवा काफी विशिष्ट POCO ऑब्जेक्ट लौटाती है (अधिक डोमेन से निर्मित - उदाहरण के लिए, उपयोगकर्ता और उनके द्वारा बनाई गई फ़ाइलें), कुछ मामलों में एक सेवा केवल डोमेन मॉडल लौटाती है - उदाहरण के लिए, "FindUserByEmail () का परिणाम उपयोगकर्ता डोमेन मॉडल लौटना चाहिए -" यहाँ मेरी चिंता है, कभी-कभी हमारी सेवा (एस) डोमेन मॉडल लौटाती है, कभी-कभी नए डीटीओ - और मुझे यह असंगतता पसंद नहीं है, मैं उतना ही लेख पढ़ता हूं जितना मैं और बहुमत सहमत हो सकता है कि मैपिंग डोमेन मॉडल <-> डीटीओ 1: 1 है, डोमेन मॉडल को सर्विस लेयर नहीं छोड़ना चाहिए - इसलिए मैं फटा हुआ हूं।
रॉबर्ट गोल्डवेइन

ऐसे परिदृश्य में और बशर्ते कि आप अतिरिक्त विकास के प्रयास को सहन कर सकें, मैं भी मैपिंग के साथ जाऊंगा ताकि आपकी लेयरिंग अधिक सुसंगत हो।
17

1

मेरे अनुभव में, जब तक आप OO UI पैटर्न (नग्न वस्तुओं की तरह) का उपयोग नहीं कर रहे हैं, तब तक यूआई के लिए डोमेन ऑब्जेक्ट्स को उजागर करना एक बुरा विचार है। ऐसा इसलिए है क्योंकि जैसे-जैसे एप्लिकेशन बढ़ता है, UI की ज़रूरतें बदल जाती हैं और आपकी वस्तुओं को उन परिवर्तनों को समायोजित करने के लिए मजबूर करती हैं। आप अंत में 2 स्वामी की सेवा करते हैं: UI और DOMAIN जो एक बहुत ही दर्दनाक अनुभव है। मेरा विश्वास करो, तुम वहाँ रहना नहीं चाहते। UI मॉडल में उपयोगकर्ता के साथ संवाद करने का कार्य है, DOMAIN मॉडल व्यावसायिक नियम रखने के लिए है और दृढ़ता मॉडल डेटा को प्रभावी ढंग से संग्रहीत करने का काम करता है। वे सभी आवेदन की विभिन्न आवश्यकताओं को संबोधित करते हैं। मैं इस बारे में एक ब्लॉग पोस्ट लिखने के बीच में हूं, जब यह हो जाएगा तो इसे जोड़ देगा।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.