डोमेन संचालित डिजाइन में एक इकाई और कुल के बीच अंतर

Question

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

Answer 1

परिभाषा काफी सीधे आगे है:

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

कुल डोमेन-संचालित डिज़ाइन में एक पैटर्न है। एक डीडीडी कुल डोमेन ऑब्जेक्ट्स क्लस्टर है जिसे एक इकाई के रूप में माना जा सकता है। एक उदाहरण एक ऑर्डर और इसकी लाइन-आइटम हो सकता है, ये अलग-अलग ऑब्जेक्ट्स अलग होंगे, लेकिन ऑर्डर का इलाज करने के लिए उपयोगी है (इसकी लाइन आइटम के साथ) एक समग्र के रूप में।

कुल मिलाकर इसकी घटक वस्तुओं में से एक को रूट होना चाहिए। कुल के बाहर से कोई भी संदर्भ केवल कुल रूट पर जाना चाहिए। इस प्रकार रूट पूरी तरह से की अखंडता सुनिश्चित कर सकता है।

समेकन डेटा संग्रहण के हस्तांतरण का मूल तत्व हैं - आप पूरे योग को लोड या सहेजने का अनुरोध करते हैं। लेनदेन पार सीमाओं को पार नहीं करना चाहिए।

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

• निकाय: एक डाटा मॉडल संदर्भ में, डेटा की संरचना संग्रहीत प्रपत्र की परवाह किए बिना वर्णन करता है।

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

परिभाषा भिन्न हो सकती है, जिन्हें मार्टिन फाउलर और माइक्रोसॉफ्ट द्वारा परिभाषित किया गया है। उम्मीद है कि हालांकि अंतर को स्पष्ट करता है।

Answer 2

डोमेन संचालित डिजाइन परिप्रेक्ष्य से DbContext यूनिटऑफवर्क का कार्यान्वयन है और DbSet<T> एक भंडार का कार्यान्वयन है।

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

तो, कुल रूट क्या है?

मान लें कि हमारे पास सोशल नेटवर्क है और इकाइयां पोस्ट, पसंद, टिप्पणी, टैग जैसी हैं। (मुझे विश्वास है कि आप इन इकाइयों के बीच संबंधों की कल्पना कर सकते हैं) कुछ इकाइयां "कुल रूट"

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