बस एमवीसी शोध करना शुरू किया, और मुझे यकीन नहीं है कि मैं इसे अभी तक समझता हूं। जो मैं इकट्ठा करता हूं उससे यह 3 स्तरीय समाधान के कार्यान्वयन की तरह लगता है यानी मॉडल डीएएल से मेल खाता है, व्यापार तर्क परत के नियंत्रक, और प्रस्तुति परत के रूप में देखें।एमवीसी - क्या यह सिर्फ 3 स्तरीय मॉडल है?
क्या मैं यहाँ आधार से बाहर हूं?
मैं मॉडल को डेटा एक्सेस लेयर के रूप में पेश करने के खिलाफ सावधानी बरतता हूं। यह oversimplifying है, और इसके परिणामस्वरूप आप नियंत्रक परत में बहुत अधिक कोड डालते हैं। यह बेहतर है कि यदि आप मॉडल में उस कोड को अधिक डालते हैं, और डेटाबेस दृढ़ता मॉडल के आंतरिक कोड का केवल एक हिस्सा बनाते हैं। मैं इस तरह MVC के बारे में सोचना चाहते:
यह मूल रूप से Page Controller पैटर्न तक सीमित नहीं है।
इसके बारे में सोचने का एक और तरीका यह है: मान लीजिए कि आपको अपने वेब ऐप को किसी अन्य प्लेटफॉर्म पर पोर्ट करना होगा, जैसे कमांड लाइन ऐप या डेस्कटॉप जीयूआई ऐप। आवेदन तर्क के किस हिस्से का आप पुन: उपयोग करना चाहिए? जब आप अपने ऐप को किसी अन्य प्लेटफॉर्म पर पोर्ट करते हैं तो नियंत्रक और दृश्य बदल जाएगा, क्योंकि इनपुट और आउटपुट दोनों के कार्यान्वयन को बदलने की आवश्यकता होगी। जिस कोड को बदलने की आवश्यकता नहीं है उसे आपके मॉडल में लागू किया जाना चाहिए।
यदि आपने सही चिंताओं को अलग किया है, तो मॉडल, व्यू, और कंट्रोलर को कम से कम जोड़ा जाएगा, और आप दूसरों को प्रभावित किए बिना किसी के कार्यान्वयन को बदल सकते हैं। यदि आप मॉडल बदलते हैं और आप स्वयं को नियंत्रक या दृश्य में बहुत से कोड को फिर से लिखते हैं, तो संभवतः आपने इन परतों को पर्याप्त रूप से अलग नहीं किया है। और इसके विपरीत।
कुछ अन्य दृष्टिकोण प्राप्त करने के लिए मार्टिन फाउलर के Anemic Domain Model एंटीपाटर या Domain Driven Design Quickly के बारे में पढ़ें।
मेरे blog from 2008 को भी देखें जो मैंने सक्रिय रिकॉर्ड पैटर्न को अस्वीकार करने वाले लोगों के जवाब में लिखा था। इसे कुछ अच्छी टिप्पणियां और चर्चा मिली।
क्रमबद्ध करें। यह इस तरह दिखता है:
पैटर्न सबसे अधिक आज प्रयोग किया जाता है:
Database -> DAL -> BLL -> Controller -> View Model -> UI
कहाँ
DAL == Data Access Layer (aka ORM, Object-Relational mapper)
BLL == Business Logic Layer
ध्यान दें कि आप हमेशा नहीं है हर परत की जरूरत है। उदाहरण के लिए, बीएलएल और व्यू मॉडल वैकल्पिक हो सकता है यदि ऐप पर्याप्त छोटा हो।
आपको NerdDinner tutorial. की जांच करनी चाहिए यह इन सभी अवधारणाओं को एक संदर्भ में वर्णित करता है।
कुछ महान स्पष्टीकरण यहाँ अगर आप MVC के लिए नए हैं:
एक छोटी टिप्पणी, आप सही हैं जब आप कहते हैं नियंत्रक कर सकते हैं व्यापार परत (की जरूरत नहीं है), और दृश्य प्रस्तुति परत है।
हालांकि मॉडल वस्तुएं हैं (कार्यान्वयन के आधार पर) जिसमें डेटा होता है, जबकि डेटा परत एक परत होती है जो डेटा को पुनर्प्राप्त/कुशल बनाती है।
मैं सहमत हूं। स्कीनी नियंत्रक और वसा मॉडल मेरे जीवन को आसान बनाते हैं। –