एएसपी.नेट एमवीसी समाधान (डीडीडी)

Question

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

धन्यवाद

अल्बर्टो

Answer 1

मुझे व्यक्तिगत रूप से लगता है कि प्रत्येक परत को एक अलग परियोजना में विभाजित करना एक बेहतर विचार है। ऐसी कुछ चीजें हैं जिन्हें आप 1 बड़ी एएसपी.नेट एमवीसी परियोजना के साथ प्राप्त नहीं कर सकते हैं जिसमें आपकी सभी परतें शामिल हैं।

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

ध्यान दें कि यदि उत्पाद, ProductFactory और अपने नियंत्रक एक ही परियोजना में हैं, तो आप अभी भी उत्पाद के निर्माता अपने नियंत्रक में देख सकते हैं। तो एक शौकिया डेवलपर जो आपके डिज़ाइन के पीछे आर्किटेक्चरल फैसलों को नहीं समझता है और उत्पाद फैक्टरी को अनदेखा कर सकता है और उत्पाद ऑब्जेक्ट सीधे बना सकता है।

प्लस, प्रत्येक परत के लिए एक अलग परियोजना होने से आपका रखरखाव आसान हो जाता है क्योंकि आपको 1 बड़ी परियोजना के विपरीत छोटी परियोजनाओं से निपटना होगा।

Answer 2

Jimmy Bogard (Automapper के लेखक) कैसे वह संरचनाओं अपने कोड है, जो अपने निर्णय की मदद करने में मदद कर सकते हैं पर एक उत्कृष्ट article लिखा है।

मैंने कई अलग-अलग असेंबली और परियोजनाओं के साथ परियोजनाओं पर काम किया है जिनके पास एक छोटी संख्या है। मेरी निजी प्राथमिकता कम असेंबली है क्योंकि मुझे हमेशा काम करना आसान लगता है। यदि आप अच्छे कोडिंग सिद्धांतों (जैसे सोलिड) का उपयोग करते हैं तो इससे कोई फर्क नहीं पड़ता कि आप 2 या 20 असेंबली का उपयोग करते हैं।

Answer 3

यह निर्भर करता है कि आपकी परियोजना कितनी बड़ी है, लेकिन मैं मॉडल और भंडार के लिए विभिन्न परियोजनाओं के लिए जाऊंगा। मेरी राय में, वेब मॉडल एमवीसी परियोजना के मॉडल फ़ोल्डर में अपने मॉडल की सामग्री को रखने के लिए उपयुक्त नहीं है। यह बहुत भीड़ हो जाता है :)

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

भंडार पैटर्न के अतिरिक्त, भंडार से आने वाले डेटा को फ़िल्टर करने के लिए विनिर्देश पैटर्न का उपयोग करने पर विचार करें।

Answer 4

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