एक एमवीसी वेब अनुप्रयोग के लिए डोमेन संचालित डिजाइन बनाम डाटाबेस संचालित डिजाइन

Question

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

नई परियोजना दो प्राथमिक लक्ष्य

• तानाना (वर्तमान के लिए और भविष्य पाइपलाइन आवश्यकताओं)
• प्रदर्शन

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

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

या डीडीडी में दोनों को हासिल करने के लिए एक तरीका है, डीडीडी प्रदान करता है और प्रदर्शन करता है कि डीबीडीडी प्रदान करता है?

Answer 1

क्या आपने कमांड क्वेरी सेपरेशन का कुछ रूप माना है, जहां डोमेन मॉडल के माध्यम से अपडेट अभी भी डेटा रीडर के रूप में आते हैं? पूर्ण उड़ा डीडीडी हमेशा उपयुक्त नहीं है।

Answer 2

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

ही कहते हैं एक व्यापार वस्तु और एक डेटा एक्सेस ऑब्जेक्ट

क्यों 'आरंभ' है महंगा प्रारंभ? आप किस डेटा एक्सेस तंत्र का उपयोग कर रहे हैं?

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

इसके लिए क्या फायदेमंद है, एनएचबीर्नेट को केवल एप्लिकेशन स्टार्टअप पर एक बार आरंभ करने की आवश्यकता है, इसके बाद यह आपके नियमित डेटा पाठकों के समान ADO.NET कनेक्शन पूल का उपयोग करता है। तो यह सब एक उचित मानचित्रण, रणनीति लाने और 'एन + 1 चयन' जैसे क्लासिक डेटा पहुंच गलतियों से परहेज करने के लिए उबलता है।

Answer 3

"अब सख्त डीडीडी के साथ डेटा के लिए किसी भी कॉल को बिजनेस लेयर और डेटा एक्सेस लेयर के माध्यम से भेजा जाएगा।"

मुझे विश्वास नहीं है कि यह सच है, और यह निश्चित रूप से व्यावहारिक नहीं है। मेरा मानना ​​है कि यह पढ़ना चाहिए:

अब सख्त DDD के साथ जगह में, एक लेनदेन के लिए किसी भी कॉल व्यापार परत और डेटा का उपयोग परत के माध्यम से कराई जाएगी।

ऐसा कुछ भी नहीं है जो कहता है कि आप स्क्रीन पर प्रदर्शित करने के लिए आवश्यक डेटा लाने के लिए सीधे डेटा एक्सेस लेयर को कॉल नहीं कर सकते हैं। यह तभी होता है जब आपको उस डेटा को संशोधित करने की आवश्यकता होती है जिसे आपको अपने डोमेन मॉडल को आमंत्रित करने की आवश्यकता होती है जो उसके व्यवहार के आधार पर डिज़ाइन की गई है। मेरी राय में यह एक महत्वपूर्ण भेद है। यदि आप अपने डोमेन मॉडल के माध्यम से सबकुछ रूट करते हैं तो आपको तीन समस्याएं होंगी:

1. समय - यह आपको बिना किसी लाभ के कार्यक्षमता को लागू करने के लिए बहुत अधिक समय लेगा।
2. मॉडल डिज़ाइन - व्यवहार के बजाय पूछताछ की जरूरतों को पूरा करने के लिए आपका डोमेन मॉडल आकृति से बाहर हो जाएगा।
3. प्रदर्शन - अतिरिक्त परत की वजह से नहीं, लेकिन क्योंकि आप सीधे अपने प्रश्न से सीधे डेटा से प्राप्त डेटा प्राप्त करने में सक्षम नहीं होंगे। यानी किसी विशेष ग्राहक के लिए रखे गए सभी आदेशों के कुल मूल्य पर विचार करें - ग्राहक के लिए सभी ऑर्डर इकाइयों को लाने के लिए इसके लिए एक प्रश्न लिखना बहुत तेज़ है, फिर से शुरू करें और योग करें।

जैसा कि क्रिसयरे 2000 ने उल्लेख किया है, सीक्यूआरएस का उद्देश्य इन सटीक मुद्दों को हल करना है।