डीडीडी: ई-कॉमर्स नमूना के अलावा आवेदन को बढ़ाए गए संदर्भों में कैसे विभाजित करें?

Question

हमारे यहां एक बहुत बड़ा आवेदन है और मैं इसे डीडीडी लड़कों के मार्गदर्शन का पालन करने के लिए थोड़ा सा रिफैक्टर करने पर विचार कर रहा हूं।

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

Answer 1

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

उदाहरण आप दे के साथ

, कुछ विकल्प हैं:

• एक बड़े घिरे संदर्भ
• अलग घिरे संदर्भों, डुप्लिकेट किए गए डेटा के साथ
• (संभवतः एक प्रकाशित करें/सदस्यता लें संदेश प्रणाली का उपयोग करके लागू) उपयोगकर्ता और कैटलॉग इटम्स को अपने स्वयं के बाध्य संदर्भ में खींचें और अन्य बाध्य संदर्भों को उन्हें सेवा के माध्यम से एक्सेस करें

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