डोमेन फ्रेमवर्क डिज़ाइन की एंटिटी फ्रेमवर्क के साथ नुकसान


12

डीडीडी पर बहुत सारे ट्यूटोरियल जो मैंने अध्ययन किए हैं वे ज्यादातर सिद्धांत को कवर कर रहे हैं। उन सभी के पास अल्पविकसित कोड उदाहरण (Pluralsight और समान) हैं।

वेब पर EF के साथ DDD को कवर करने वाले ट्यूटोरियल बनाने के लिए कुछ लोगों द्वारा प्रयास भी किए जाते हैं। यदि आप उन्हें संक्षेप में अध्ययन करना शुरू करते हैं - आप जल्दी से नोटिस करते हैं कि वे एक दूसरे से बहुत भिन्न हैं। कुछ लोग ऐप को कम से कम रखने और अतिरिक्त परतों को पेश करने से बचने की सलाह देते हैं, जैसे कि EF के शीर्ष पर भंडार , अन्य निश्चित रूप से अतिरिक्त परतें उत्पन्न कर रहे हैं, अक्सर DbContextएग्रिगेट रूट्स में इंजेक्ट करके SRP का भी उल्लंघन करते हैं।

अगर मैं एक राय-आधारित प्रश्न पूछ रहा हूँ, तो मैं बहुत माफी माँग रहा हूँ, लेकिन ...

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


महत्वपूर्ण पहलू:

  • एंटिटी फ्रेमवर्क UoW & Repository ( DbSet) बॉक्स से बाहर लाता है

  • EF के साथ आपके मॉडल में नेविगेशन गुण हैं

  • एफई के साथ मॉडल के सभी हमेशा से रहे हैं उपलब्ध बंद DbContext(वे एक के रूप में प्रतिनिधित्व कर रहे हैं DbSet)

नुकसान:

  • आप गारंटी नहीं दे सकते कि आपके बच्चे मॉडल केवल एग्रीगेट रूट के माध्यम से प्रभावित होते हैं - आपके मॉडल में नेविगेशन गुण हैं और उन्हें संशोधित करना और कॉल करना संभव हैdbContext.SaveChanges()

  • साथ DbContextआप अपने हर मॉडल का उपयोग कर सकते हैं, इस प्रकार circumventing सकल रूट

  • आप के माध्यम से जड़ वस्तु के बच्चों के लिए उपयोग को प्रतिबंधित कर सकते ModelBuilderमें OnModelCreatingविधि उन्हें फ़ील्ड के रूप में चिह्नित करके मैं अब भी यह DDD के बारे में जाने के लिए सही रास्ता है पर विश्वास नहीं है प्लस यह रोमांच की किस तरह यह भविष्य में पैदा हो सकती है मूल्यांकन करने के लिए मुश्किल है (- काफी उलझन में )

संघर्ष:

  • रिपॉजिटरी की एक और परत को लागू किए बिना जो एग्रीगेट को वापस लौटाती है हम उपर्युक्त नुकसानों को आंशिक रूप से हल नहीं कर सकते हैं

  • रिपॉजिटरी की एक अतिरिक्त परत को लागू करके हम ईएफ (हर DbSetपहले से ही एक रेपो) की अंतर्निहित विशेषताओं को अनदेखा कर रहे हैं और ऐप को अधिक जटिल बना रहे हैं


मेरा निष्कर्ष:

कृपया मेरी अज्ञानता को क्षमा करें, लेकिन उपरोक्त जानकारी के आधार पर - यह या तो एंटिटी फ्रेमवर्क डोमेन-ड्रिवेन डिज़ाइन के लिए पर्याप्त नहीं है या डोमेन-ड्रिवेन डिज़ाइन एक अपूर्ण और अप्रचलित दृष्टिकोण है।

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


अगर मैं गलत हूं - तो कोई भी कम से कम निर्देशों का एक साधारण सेट (या यहां तक ​​कि सभ्य कोड उदाहरण प्रदान कर सकता है) कैसे डीडीडी के बारे में ईएफ के साथ जाने के लिए, कृपया?


ईएफ कैसे काम करता है, इसकी मेरी समझ के अनुसार मैंने यहां विस्तृत कदम उठाए । फिर भी वे कदम बच्चों को नौसैनिकों तक पहुँचने की समस्या से नहीं निपटते। DbContext से गुण या DbSets द्वारा।
एलेक्स हरमन

जवाबों:


8

DDD और EF का एक दूसरे से कोई लेना देना नहीं है।

DDD एक मॉडलिंग कॉन्सेप्ट है। इसका मतलब डोमेन, व्यावसायिक आवश्यकताओं और उन लोगों के बारे में सोचना है। विशेष रूप से ऑब्जेक्ट-ओरिएंटेशन के संदर्भ में इसका मतलब है कि एक डिज़ाइन बनाना जो व्यावसायिक कार्यों और क्षमताओं को प्रतिबिंबित करता है।

ईएफ एक दृढ़ता तकनीक है। यह मुख्य रूप से डेटा और डेटाबेस रिकॉर्ड से संबंधित है।

ये दोनों तेजी से तलाकशुदा हैं। एक DDD डिज़ाइन ईडी का उपयोग हुड के तहत किसी रूप में कर सकता है, लेकिन दोनों को किसी अन्य तरीके से बातचीत नहीं करनी चाहिए।

Domain-Driven Design की कुछ व्याख्याएं वास्तव में डेटा-मॉडलिंग की वकालत करती हैं, और मुझे लगता है कि यह आपका सवाल है। इस व्याख्या में "एंटिटीज" और "वैल्यू ऑब्जेक्ट्स" अनिवार्य रूप से केवल फ़ंक्शन-कम डेटा धारक हैं, और डिज़ाइन खुद को चिंतित करता है कि ये गुण क्या हैं और वे एक दूसरे के बीच क्या संबंध रखते हैं। इस संदर्भ में DDD बनाम EF सामने आ सकते हैं।

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

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


1
EF सिर्फ एक समय बचाने है। परिवर्तन-ट्रैकिंग और समुच्चय की दृढ़ता वह जगह है जहाँ EF पहले से ही बहुत मदद करता है। दुर्भाग्य से, वर्तमान में कॉन्फ़िगरेशन स्तर पर कुलियों के आकार को परिभाषित करने का कोई तरीका नहीं है।
पावेल वोरोनिन

6

यह क्या है यानी डेटा एक्सेस लाइब्रेरी जो केवल ADO.NET की तुलना में थोड़ी अधिक दृढ़ता से टाइप की जाती है, के लिए ईएफ का इलाज करें। मैं आपके डोमेन को ईएफ इकाई वर्गों का उपयोग करने के लिए अनुशंसित नहीं करूंगा जैसे मैं कच्चे डेटासेट या डेटाटेबल का उपयोग करके मॉडल डोमेन की सिफारिश नहीं करूंगा।

मैं समझता हूं कि EF को डेटाबेस एक्सेस और डोमेन मॉडलिंग के बीच एक शॉर्टकट के रूप में बेचा जा रहा है लेकिन यह दृष्टिकोण आंतरिक रूप से त्रुटिपूर्ण है क्योंकि यह दो बड़े पैमाने पर असंबद्ध समस्याओं को संबोधित करता है। .NET में अन्य प्रयास थे कि एक वर्ग पूरी तरह से असंबंधित चीज़ों को निष्पादित करने के लिए (जैसे .NET रीमोटिंग) और वे अच्छी तरह से समाप्त नहीं हुए।

POCO क्लासेस का उपयोग कर DDD करें और डेटाबेस स्कीमा को अपना डिज़ाइन चलाने न दें। EF को रिपॉजिटरी / दृढ़ता परत के अंदर रखें और EF संस्थाओं को बाहर रिसाव न होने दें।


5

एंटिटी फ्रेमवर्क UoW & Repository (DbSet) को बॉक्स से बाहर लाता है

नहीं।

इकाई फ्रेमवर्क सार ORD के साथ बनाया गया था, न कि DDD को ध्यान में रखते हुए। DbSetइकाई की रूपरेखा के किसी भी संस्करण में अमूर्त एक DDD भंडार की सादगी के पास कहीं भी नहीं है - उल्लेख करने के लिए नहीं DbContextहै जो एक असंख्य चीजें एक UnitOfWork की तुलना में अधिक उजागर करता है।

यहाँ EF Core 2.1 के सार में तत्वों की एक गैर-विस्तृत सूची है, DbSet<TEntity>जिसकी हमें DDD में आवश्यकता नहीं है:

  • Attach(TEntity) और उसके सभी भाई-बहन
  • Find(Object[])
  • Update(TEntity) और उसके सभी भाई-बहन
  • क्रियान्वयन IQueryable

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

नीचे पंक्ति: आपको इन फेटियों को अच्छी, सुव्यवस्थित अवधारणाओं में लपेटना चाहिए और अनुमान लगाना चाहिए कि अतिरिक्त कक्षाओं को शुरू करने का क्या मतलब है।

EF और DDD के साथ आप क्या कर सकते हैं, इसका एक अपेक्षाकृत ध्वनि उदाहरण (हालांकि व्यक्त किए गए कुछ बिंदु विवादास्पद हैं): https://kalele.io/blog-posts/modeling-aggregates-with-ddd-and-entity-framework/

अन्य लोग निश्चित रूप से अतिरिक्त परतें पैदा कर रहे हैं, अक्सर एसआरपी का उल्लंघन करते हुए डबकोनेट को एग्रीगेट रूट में इंजेक्ट करके

मैं वास्तव में इस वाक्य के दो भागों के बीच संबंध नहीं देखता हूं। कोई फर्क नहीं पड़ता है, डीडीडी में एक चीज है जिसे एप्लिकेशन सर्विस कहा जाता है और यही वह जगह है जहां आप यूनिट ऑफ वर्क / रिपोजिटरी (या DbContext) में हेरफेर करते हैं । एग्रीगेट रूट्स में नहीं।

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


2

संघर्ष:

रिपॉजिटरी की एक और परत को लागू किए बिना जो एग्रीगेट को लौटाता है हम भी> आंशिक रूप से उपर्युक्त कमियों को हल नहीं कर सकते हैं

रिपॉजिटरी की एक अतिरिक्त परत को लागू करके हम EF की अंतर्निहित विशेषताओं (हर DbSet पहले से ही एक रेपो) को अनदेखा कर रहे हैं और ऐप को अधिक जटिल बना रहे हैं

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

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



DBContext Per Aggregate दृष्टिकोण के कोई लाभ हैं? क्या डीडी को ईएफ के साथ लागू करने का यह डिफ़ॉल्ट तरीका है?
एलेक्स हरमन

क्या जूली लर्मन का मतलब नहीं था DbContext प्रति बद्ध संदर्भ?
संशोधन

0

विचार के लिए संभव समाधान साझा करना चाहेंगे:

  1. सीधे सेवा परत में ईएफ परियोजना को संदर्भित करने से बचें

  2. एक अतिरिक्त रिपॉजिटरी लेयर बनाएं (EF प्रोजेक्ट का उपयोग करता है और एग्रीगेट रूट लौटाता है)

  3. सेवा परत परियोजना में रिपोजिटरी लेयर का संदर्भ

वास्तुकला :

  • यूआई

  • नियंत्रक परत

  • सेवा परत

  • रिपोजिटरी लेयर

  • इकाई की रूपरेखा

  • कोर प्रोजेक्ट (EF मॉडल शामिल हैं)


मैं इस दृष्टिकोण के साथ देख रहा हूँ:

  • यदि एक रिपॉजिटरी एग्रेट रूट को ईएफ मॉडल ट्री के रूप में नहीं लौटाती है (जैसे हम एक मैप की गई वस्तु लौटाते हैं) - हम ईएफ की ट्रैकिंग परिवर्तनों की क्षमता खो रहे हैं

  • अगर एग्रिगेट रूट एक ईएफ मॉडल है - इसके सभी नेविगेशन गुण अभी भी उपलब्ध हैं , भले ही हम इससे निपट नहीं सकते DbContext(हम सेवा परत में ईएफ परियोजना का संदर्भ नहीं देते हैं)

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