डीडीडी + स्तरित आर्किटेक्चर में ऑटोमैपर को कार्यान्वित करने के लिए

Question

पृष्ठभूमि: अपनी स्पष्टता/आत्म शिक्षा के लिए, मैं टीडीडी + डीडीडी का उपयोग करके एक साधारण ऑर्डर एंट्री एप्लिकेशन को लागू करने की कोशिश कर रहा हूं। मेरा प्राथमिक लक्ष्य चिंताओं को अलग करके वास्तुकला को साफ रखना है।

मैं चार परतों (अब के लिए) ...

1. हठ/DAL एक CustomerRepository वर्ग है कि "सकल रूट" पर GetById, सहेजें, कार्रवाई कर सकते हैं के साथ, एक ग्राहक और इससे संबंधित आदेश है और ऑर्डर इटम्स। "गरीब व्यक्ति की निर्भरता इंजेक्शन" की अनुमति देने के लिए

2. डोमेन/बीएलएल परत जिसमें "व्यावसायिक इकाई" वर्ग शामिल हैं जो नए आदेश बनाने में मदद करने के लिए जुर्माना संचालन करते हैं, कर आकार, टैक्स, छूट, शिपिंग आकार को ऑर्डर आकार के आधार पर लागू करते हैं और ग्राहक स्थान

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

4. प्रस्तुति परत

इसके अलावा, मैं POCO डीटीओ के पारित करने के लिए कुंजी परतों के बीच ... विशेष रूप से हठ => डोमेन परतों के बीच, और ApplicationFacade => प्रस्तुति परतों चाहते हैं। इसलिए, मेरे पास एक साझा पैकेज में परिभाषित उचित संबंधों के साथ ग्राहक डॉट, ऑर्डर डीटी, ऑर्डर इटैम है।

मैं कन्स्ट्रक्टर इंजेक्शन का उपयोग कर ग्राहक "व्यापार इकाई" कक्षा में आईसी कस्टमर रिपोजिटरी के कार्यान्वयन को इंजेक्ट करना चाहता हूं, फिर निर्माण/अद्यतन प्रक्रिया को बंद करने के लिए "व्यापार इकाई" पर एक ग्राहक.Save() को कॉल करें, अंत में कॉल करना ग्राहक रिपोजिटरी पर सहेजें विधि। आखिरकार, ग्राहक "कुल रूट" है और इसमें सहेजने के लिए आवश्यक सभी जानकारी है ... यह इंजेक्शन ग्राहक रिपोजिटरी का "रखरखाव" भी है।

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

समस्या यह है ... यदि मैं डोमेन/बीएलएल परत में ऑटोमैपर नहीं डालता, तो मुझे वास्तव में नहीं है जहां जाना चाहिए।

इसे एप्लिकेशन फ़ैकेड में डालने का अधिकार नहीं है, भले ही यह नौकरी ऑर्केस्ट्रेशन है।

यह निश्चित रूप से डोमेन/बीएलएल परत में डालने का अधिकार नहीं है क्योंकि मैं इसे प्राचीन रखना चाहता हूं।

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

Answer 1

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

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

अंत में, प्रेजेंटेशन परत और डीटीओ के साथ एप्लिकेशन/डोमेन परत के बीच संवाद करने के लिए यह एक आम प्रथा है। यह निर्धारित करने के लिए कि मैपिंग कहां होनी चाहिए, आपको आर्किटेक्चर में गहराई से खोदना होगा जो आपकी परियोजना के लिए उपयुक्त है। अधिकांश आधुनिक डीडीडी आर्किटेक्चर Hexagonal architecture पर आधारित हैं। हेक्सागोनल आर्किटेक्चर में, आपका डोमेन केंद्र में है और अन्य सभी "परतें" डोमेन को विशिष्ट तकनीकों में अनुकूलित करती हैं। उदाहरण के लिए, डोमेन और एक विशिष्ट डेटाबेस तकनीक के बीच adapter के रूप में एक संग्रह को देखा जा सकता है। एएसपी.नेट वेबएपीआई को डोमेन और HTTP/REST के बीच एडाप्टर के रूप में देखा जा सकता है। इसी प्रकार, प्रस्तुति परत को डोमेन और एक विशिष्ट के बीच एडाप्टर के रूप में देखा जा सकता है। डीटीओ इन एडाप्टर में से प्रत्येक के भीतर प्रकट हो सकते हैं और यह इन डीटीओ से और उससे मैप करने के लिए एडाप्टर की ज़िम्मेदारी है।

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