एएसपी.नेट एमवीसी: कहां जाता है?

Question

मैं एक मध्यम आकार के एएसपी.NET एमवीसी अनुप्रयोग को विकसित करना शुरू कर रहा हूं। मैं डिजाइन को सही करने की कोशिश कर रहा हूं। मैं निम्नलिखित परतें करने का इरादा:

• यूआई परत (MVC)
• सेवा लेयर
• भंडार लेयर
• डेटा एक्सेस परत

मैं अपने आईओसी कंटेनर के रूप में एकता का उपयोग किया जाएगा और डेटा एक्सेस के लिए EF4.1 कोड पहले।

ऐप को कई असेंबली में विभाजित किया जाएगा। मैं निर्णय लेने से जो विधानसभाओं मैं और जहां आवश्यकता होगी निम्नलिखित डाल करने के लिए एक समस्या है:

• संस्थाओं/डोमेन जैसे वस्तुओं ग्राहक, चालान
• डीटीओ उदा। ग्राहक डीटीओ, चालान डीटीओ
• सेवा इंटरफेस उदा। ICustomerService
• रिपोजिटरी इंटरफेस उदा। ICustomerRepository
• सेवाएं (सेवा इंटरफ़ेस कार्यान्वयन कक्षाएं) उदा। Customerservice
• डेटा संग्रह स्थान (भंडार सेवा कार्यान्वयन वर्ग) जैसे CustomerRepository
• ViewModels उदा CustomerViewModel
• Enums

मेरा प्रश्न है: कैसे आप आमतौर पर तुम्हारा विभाजित हैं और क्यों?

संपादित करें: @ TheHurt के जवाब द्वारा प्रेरित किया।

कैसे संदर्भ विधानसभाओं, अर्थात के बीच होगा जो विधानसभा जो संदर्भित हो सकता है?

Answer 1

यह मैं इसे कैसे से निपटने दे सकती हैं:

App.UI विधानसभा:

• ViewModels मॉडल क्षेत्र में जाना।

App.Repository विधानसभा:

• ठोस भंडार का सार कार्यान्वयन।
• ICustomerRepository

App.Repository.SQL:

• कंक्रीट कार्यान्वयन।
• EFCF Pocos

App.Services विधानसभा:

• सार सेवा।
• ICustomerService
• DTOs

App.Services.Implementation:

• कंक्रीट सेवा।
• customerservice

App.Common:

• साझा कोड।
• Enums

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

संपादित

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

साइड नोट, मैं जितना संभव हो सके "धातु" से दूर रहने की कोशिश करता हूं, जबकि एक ऐसा डिज़ाइन विकसित करता है जो मुझे भविष्य में विभिन्न परतों में कोड को अलग करने की अनुमति देगा। अगर मैं कागज़ की एक शीट के साथ अपने प्रबंधक को विभिन्न सिस्टम परतों को स्पष्ट रूप से समझा नहीं सकता, तो डिजाइन संभवतः जटिल से अधिक है। अधिकांश भाग के लिए सब कुछ Visio में सुंदर लगेगा यदि यह अच्छी तरह से डिज़ाइन किया गया है।

जहां तक ​​चीजें एक-दूसरे को संदर्भित करती हैं: यूआई सेरिवेस (या सेवा कार्यान्वयन, जिसे आवश्यकता नहीं हो सकती है) को रेफरी करेगा। बस इसे एक ही स्थान पर रखें।)। सेवा रिपोजिटरी refs। भंडार कार्यान्वयन कुछ भी नहीं करता है, क्योंकि यह आईओसी द्वारा लोड किया जाता है। सबकुछ आम है।