एएसपी.नेट एमवीसी, परतें, मॉडल, रिपोजिटरीज इत्यादि

Question

Layered Application Guidelines (http://msdn.microsoft.com/en-us/library/ee658109.aspx) नामक लेख पढ़ने के बाद मेरे कुछ प्रश्न हैं।

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

ऊपर दिए गए लेख के अनुसार उन्हें परतों में कैसे विभाजित करें?

जहां तक ​​मैं समझता हूं, दृश्य और (शायद) नियंत्रक प्रस्तुति परत में रहते हैं। डेटा लेयर में बिजनेस लेयर और रिपोजिटरीज, यूनिटऑफवर्क और डीबी कॉन्टेक्स्ट में इकाइयां (मॉडल)।

क्या मैं सही या गलत हूं? मैं इसके बारे में बहुत अनिश्चित हूं।

अग्रिम धन्यवाद!

Answer 1

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

Answer 2

परतों को अलग करने का तरीका आपके आवेदन के दायरे पर निर्भर करेगा। एक छोटे से के लिए, क्षेत्र पर्याप्त हो सकता है। एक बड़ी परियोजना के लिए, या एक परियोजना जो बड़ी हो सकती है, आपको प्रत्येक परत के लिए अलग-अलग समाधान बनाने में देखना चाहिए। इसे एन-टियर दृष्टिकोण के रूप में जाना जाता है, और http://prodinner.codeplex.com/ पर उत्कृष्ट उदाहरण को देखते समय देखा जा सकता है।

Answer 3

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

इस पर निर्भर करता है कि आप अपना कोड कैसे अलग करते हैं (और ऐसा लगता है कि आप रिपोजिटरी पैटर्न का उपयोग कर रहे हैं) आपके पास कुछ व्यवसाय तर्क युक्त रिपोजिटरी हो सकती है, या एक सेवा परत भी हो सकती है (3 स्तरीय अनुप्रयोगों के लिए मेरी प्राथमिकता) व्यापार तर्क (ज्यादातर) होता है।

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

व्यवसाय तर्क को रोकने से रोकने के लिए सबसे महत्वपूर्ण स्थान आपकी प्रस्तुति परत है, और सबसे महत्वपूर्ण रूप से आपके दृश्य और नियंत्रक हैं। आपके शेष एप्लिकेशन को कैसे व्यवस्थित करने का दृष्टिकोण आपके द्वारा चुने गए ढांचे, आपके आवेदन का स्तर और आवेदन की तैनाती संरचना पर निर्भर करता है।

दृश्य < --Presentation परत केवल

नियंत्रकों < --Presentation परत केवल (अंत हो सकता है:

तो संभव के रूप में स्पष्ट होना यह है कि क्या मैं * करना है कुछ मामलों में थोड़ा 'वसा' नियंत्रक के साथ, उदाहरण के लिए .NET सदस्यता लॉगिन)

मॉडल देखें < - प्रस्तुति परत, लेकिन अगर यहां सत्यापन करना अक्सर व्यवसाय नियमों का परीक्षण किया जा रहा है।

सेवा लेयर < --Business लेयर डाटा इस्तेमाल किया

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

संस्थाओं < --Data परत, संभावित रूप से व्यापार तर्क के साथ आप अपने आवेदन को कैसे व्यवस्थित करते हैं।

* नहीं आधिकारिक

Answer 4

• देखें मॉडल/दृश्य/नियंत्रकों के रूप में लिया जाना चाहिए - प्रस्तुति परत
• संस्थाओं - व्यापार परत

The repository mediates between the data source layer and the business layers of the application

DbContext Represents a combination of the Unit-Of-Work and Repository patterns, इसलिए यदि आप एक भंडार और काम की इकाई को लागू कर रहे हैं इसका शीर्ष अर्थ यह हो सकता है कि आपको limit your abstractions पर विचार करना चाहिए। (यह अंतिम बिंदु आपके मामले में लागू नहीं हो सकता है, मैं आपके डिजाइन के बारे में और जानने के बिना नहीं कह सकता था)।