MVC वास्तव में क्या है?


201

एक गंभीर प्रोग्रामर के रूप में, आप इस प्रश्न का उत्तर कैसे देते हैं कि MVC क्या है?

मेरे दिमाग में, MVC एक अस्पष्ट विषय की तरह है - और उसके कारण, यदि आपके दर्शक एक शिक्षार्थी हैं, तो आप इसे सामान्य शब्दों में वर्णन करने के लिए स्वतंत्र हैं जो विवादास्पद होने की संभावना नहीं है।

हालाँकि, यदि आप एक जानकार दर्शक, विशेष रूप से एक साक्षात्कारकर्ता से बात कर रहे हैं, तो मेरे पास एक दिशा लेने के लिए सोचने का कठिन समय है जो "अच्छी तरह से सही नहीं है ..." की प्रतिक्रिया का जोखिम नहीं उठाता है। हम सभी को अलग-अलग वास्तविक अनुभव हैं, और मैं वास्तव में एक ही एमवीसी कार्यान्वयन पैटर्न से दो बार नहीं मिला हूं।

विशेष रूप से, कठोरता, घटक परिभाषा, भागों को अलग करने (क्या टुकड़ा कहाँ फिट बैठता है), आदि के बारे में असहमति प्रतीत होती है।

तो, मुझे एमवीसी को कैसे सही, संक्षिप्त और अनियंत्रित तरीके से समझाना चाहिए ?


4
नोट: यदि आप ASP.NET में काम कर रहे हैं, तो MVC का दूसरा, गैर-अस्पष्ट अर्थ है: ASP.NET MVC
ब्रायन

MVC को यहां अच्छी तरह से समझाया गया है कि कोडस्पेकर
blogs/

जवाबों:


155

MVC एक सॉफ्टवेयर आर्किटेक्चर है - सिस्टम की संरचना - जो डोमेन / एप्लिकेशन / व्यवसाय (जो भी आप पसंद करते हैं) को बाकी यूजर इंटरफेस से अलग करती है। यह आवेदन को तीन भागों में अलग करके करता है: मॉडल, दृश्य और नियंत्रक।

मॉडल एप्लिकेशन के मौलिक व्यवहार और डेटा का प्रबंधन करता है। यह जानकारी के लिए अनुरोधों का जवाब दे सकता है, इसकी सूचना की स्थिति को बदलने के लिए निर्देशों का जवाब दे सकता है, और यहां तक ​​कि जानकारी बदलने पर सिस्टम-संचालित सिस्टम में पर्यवेक्षकों को सूचित कर सकता है। यह एक डेटाबेस, या किसी भी डेटा संरचना या भंडारण प्रणाली की संख्या हो सकती है। संक्षेप में, यह एप्लिकेशन का डेटा और डेटा-प्रबंधन है।

दृश्य प्रभावी रूप से एप्लिकेशन के उपयोगकर्ता इंटरफ़ेस तत्व प्रदान करता है। यह मॉडल से डेटा को एक ऐसे रूप में प्रस्तुत करेगा जो उपयोगकर्ता इंटरफ़ेस के लिए उपयुक्त है।

नियंत्रक उपयोगकर्ता इनपुट प्राप्त करता है और मॉडल ऑब्जेक्ट्स और उचित कार्य करने के लिए कॉल करता है।

सभी में, ये तीन घटक MVC के तीन बुनियादी घटकों को बनाने के लिए एक साथ काम करते हैं।


7
+1 मैं वास्तव में एक डिज़ाइन पैटर्न की तुलना में MVC को तीन (या अधिक) पैटर्न की वास्तुकला के रूप में सोचना पसंद करता हूं। कोई विहित कार्यान्वयन नहीं है, यह बस इतना छोटा नहीं है, और सभी कार्यान्वयन निहित कोर घटकों की तुलना में काफी अधिक होंगे।
यानिस डे

51
हालाँकि इस उत्तर में 21 अपवोट्स हैं, मुझे लगता है कि वाक्य "यह एक डेटाबेस, या किसी भी डेटा संरचना या स्टोरेज सिस्टम की संख्या हो सकती है। (tl। Dr: इट्स डेटा एंड डेटा-मैनेजमेंट ऑफ़ एप्लीकेशन)" भयानक। मॉडल शुद्ध व्यवसाय / डोमेन लॉजिक है। और यह किसी एप्लिकेशन के डेटा प्रबंधन से बहुत अधिक हो सकता है और होना चाहिए। मैं डोमेन लॉजिक और एप्लिकेशन लॉजिक में भी अंतर करता हूं। एक नियंत्रक को कभी भी व्यवसाय / डोमेन तर्क नहीं होना चाहिए या सीधे डेटाबेस से बात नहीं करनी चाहिए।
फाल्कन

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

6
@ जिमी: एमवीसी के कई निर्माणों में, मॉडल को एपीआई में पुन: उपयोग किया जा सकता है, क्योंकि उनके पास यूआई पर निर्भरता नहीं है - दृश्य और मॉडल के बीच का अलगाव इसका ख्याल रखता है। लेकिन यह इस बात पर निर्भर करता है कि आप 'मॉडल' को कैसे परिभाषित करते हैं। यदि आप एमवीसी के बारे में कोई निर्णय लेने जा रहे हैं, तो आपको पहले यह बताना चाहिए कि आप एमवीसी की किस व्याख्या का उपयोग कर रहे हैं।
ओवेन एस।

5
@ यानिस: यह सिर्फ इस सवाल का जवाब देता है: पैटर्न की वास्तुकला क्या है? आप इसे सिर्फ एक और डिज़ाइन पैटर्न क्यों नहीं कहेंगे? GoF (और अलेक्जेंडर) में डिजाइन पैटर्न की बहुत परिभाषा यह स्पष्ट करती है कि पैटर्न को एक कैनोनिकल कार्यान्वयन नहीं लिखा जाना चाहिए (हालांकि दोनों पुस्तकों की लोकप्रियता थोड़ा सा ध्यान नहीं देती है)।
ओवेन एस।

135

समानता

मैंने अपने पिता को MVC को इस तरह समझाया:

MVC (मॉडल, व्यू, कंट्रोलर) स्थिरता बनाए रखने के लिए एक एप्लिकेशन में कोड को व्यवस्थित करने के लिए एक पैटर्न है।

एक स्टूडियो में अपने कैमरे के साथ एक फोटोग्राफर की कल्पना करो। एक ग्राहक उसे एक बॉक्स का फोटो लेने के लिए कहता है।

बॉक्स मॉडल है , फोटोग्राफर नियंत्रक है और कैमरा दृश्य है

क्योंकि बॉक्स को कैमरे या फ़ोटोग्राफ़र के बारे में नहीं पता है , यह पूरी तरह से स्वतंत्र है। यह पृथक्करण फोटोग्राफर को बॉक्स के चारों ओर चलने और किसी भी कोण पर कैमरे को इंगित करने की अनुमति देता है ताकि वह शॉट / दृश्य प्राप्त कर सके जो वह चाहता है।

गैर-एमवीसी आर्किटेक्चर एक साथ कसकर एकीकृत होते हैं। यदि बॉक्स, नियंत्रक और कैमरा एक-और-समान-वस्तु थे तो, हमें अलग-अलग खींचना होगा और फिर हर बार जब हम एक नया दृश्य प्राप्त करना चाहते हैं , तो बॉक्स और कैमरा दोनों को फिर से बनाएँगे । इसके अलावा, फोटो लेना हमेशा सेल्फी लेने की कोशिश करने जैसा होगा - और यह हमेशा बहुत आसान नहीं होता है।


विस्तृत विवरण

यह निम्नलिखित मैलिस्ट प्रश्न / उत्तर को पढ़ने के बाद ही मुझे लगा जैसे मुझे लगा कि मैं एमवीसी को समझ गया हूं। उद्धरण: https://mail.python.org/pipermail/python-list/2006-January/394968.html

bwaha ने लिखा:

लेखक WVPython में MVC डिज़ाइन के उदाहरण के रूप में mvctree.py को संदर्भित करता है। हालाँकि मैं अभी भी बहुत हरा हूँ इसलिए मुझे वह विशेष उदाहरण बहुत जटिल लगता है और मैं उस अलगाव को नहीं समझ रहा हूँ जिसकी लेखक सिफारिश कर रहा है।

MVC सभी चिंताओं को अलग करने के बारे में है।

मॉडल कार्यक्रम के डेटा (निजी और ग्राहक डेटा दोनों) के प्रबंधन के लिए जिम्मेदार है। दृश्य / नियंत्रक कार्यक्रम के ग्राहक डेटा के साथ बातचीत करने के लिए बाहरी दुनिया को प्रदान करने के लिए जिम्मेदार है।

मॉडल कार्यक्रम के अन्य भागों को इसके साथ बातचीत करने में सक्षम करने के लिए एक आंतरिक इंटरफ़ेस (एपीआई) प्रदान करता है। व्यू / कंट्रोलर एक बाहरी इंटरफ़ेस (GUI / CLI / वेब फॉर्म / उच्च-स्तरीय IPC / etc।) प्रदान करता है ताकि प्रोग्राम को इसके साथ संवाद करने के लिए सब कुछ सक्षम किया जा सके।

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

मॉडल में कोई दृश्य / नियंत्रक कोड नहीं है; कोई GUI विजेट कक्षाएं, संवाद बॉक्स बिछाने या उपयोगकर्ता इनपुट प्राप्त करने के लिए कोई कोड नहीं। दृश्य / नियंत्रक में कोई मॉडल कोड नहीं है; URL को मान्य करने या SQL प्रश्नों को निष्पादित करने के लिए कोई कोड नहीं है, और कोई मूल स्थिति भी नहीं है: विगेट्स द्वारा आयोजित कोई भी डेटा केवल प्रदर्शन उद्देश्यों के लिए है, और केवल मॉडल में संग्रहीत सही डेटा का प्रतिबिंब है।

अब, यहाँ एक सच्चे एमवीसी डिज़ाइन का परीक्षण किया गया है: कार्यक्रम सार में पूरी तरह कार्यात्मक होना चाहिए, यहां तक ​​कि एक व्यू / कंट्रोलर संलग्न किए बिना भी। ठीक है, बाहरी दुनिया को इसके साथ उस रूप में बातचीत करने में परेशानी होगी, लेकिन जब तक किसी को उचित आदर्श एपीआई आवेगों के बारे में पता है, तब तक कार्यक्रम डेटा को सामान्य रूप से पकड़ और हेरफेर करेगा।

यह क्यों संभव है? ठीक है, सरल उत्तर यह है कि यह सभी मॉडल और दृश्य / नियंत्रक परतों के बीच कम युग्मन के लिए धन्यवाद है। हालाँकि, यह पूरी कहानी नहीं है। क्या पूरे MVC पैटर्न के लिए महत्वपूर्ण है दिशा सभी निर्देश प्रवाह: जिसमें उन कनेक्शन चला जाता है से देखें / नियंत्रक करने के लिए मॉडल। मॉडल कभी भी दृश्य / नियंत्रक को बताता है कि क्या करना है।

क्यों? क्योंकि MVC में, जबकि व्यू / कंट्रोलर को मॉडल (विशेष रूप से, मॉडल के एपीआई) के बारे में थोड़ा जानने की अनुमति है, लेकिन मॉडल को व्यू / कंट्रोलर के बारे में कुछ भी जानने की अनुमति नहीं है।

क्यों? क्योंकि MVC चिंताओं के स्पष्ट पृथक्करण के बारे में है।

क्यों? नियंत्रण से बाहर कार्यक्रम जटिलता को रोकने और आपको दफनाने में मदद करने के लिए, डेवलपर, इसके तहत। बड़ा कार्यक्रम, उस कार्यक्रम में घटकों की संख्या अधिक होती है। और अधिक कनेक्शन उन घटकों के बीच मौजूद होते हैं, डेवलपर्स के लिए व्यक्तिगत घटकों को बनाए रखने / बढ़ाने / बदलने के लिए, या यहां तक ​​कि पूरे सिस्टम के काम करने के तरीके का पालन करना कठिन होता है। अपने आप से यह पूछें: जब कार्यक्रम की संरचना के आरेख को देखते हैं, तो क्या आप एक पेड़ या बिल्ली के पालने को देखेंगे? MVC पैटर्न परिपत्र कनेक्शन को बंद करके उत्तरार्द्ध से बचता है: B A से कनेक्ट हो सकता है, लेकिन A, B से कनेक्ट नहीं हो सकता है। इस मामले में, A मॉडल है और B व्यू / कंट्रोलर है।

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

व्यावहारिक रूप से, तब, एक दृश्य / नियंत्रक वस्तु, मॉडल के एपीआई के माध्यम से, 1. मॉडल को चीजें करने के लिए कह सकती हैं (आदेशों को निष्पादित करें), और 2. मॉडल को यह चीजें (रिटर्न डेटा) देने के लिए कहें। व्यू / कंट्रोलर लेयर निर्देश को मॉडल लेयर पर धकेलता है और मॉडल लेयर से जानकारी खींचता है

और यहीं से आपका पहला MyCoolListControl उदाहरण गलत हो जाता है, क्योंकि उस वर्ग के लिए API को उस जानकारी को धकेलने की आवश्यकता होती है , इसलिए आप परतों के बीच दो तरफ़ा युग्मन होने पर वापस आ जाते हैं, MVC नियमों का उल्लंघन करते हैं और आपको सही वापस डंप करते हैं बिल्ली की पालने की वास्तुकला जिसे आप [संभवतः] पहले स्थान पर टालने की कोशिश कर रहे थे।

इसके बजाय, MyCoolListControl वर्ग को प्रवाह के साथ जाना चाहिए, नीचे की परत से इसकी ज़रूरत के डेटा को खींचकर, जब इसे ज़रूरत हो। एक सूची विजेट के मामले में, इसका मतलब है कि आम तौर पर यह पूछने के लिए कि कितने मूल्य हैं और फिर बदले में उन वस्तुओं में से प्रत्येक के लिए पूछ रहे हैं, क्योंकि ऐसा करने का सबसे सरल और शिथिल तरीका है और इसलिए यह रखता है कि वहाँ क्या युग्मन न्यूनतम है। और यदि विजेट उपयोगकर्ता को उन मानों को अच्छी वर्णमाला के क्रम में प्रस्तुत करना चाहता है, तो वह इसका प्रतिगामी है; और इसकी जिम्मेदारी, निश्चित रूप से।

अब, एक अंतिम पहेली, जैसा कि मैंने पहले बताया था: आप एमवीसी-आधारित प्रणाली में यूआई के प्रदर्शन को मॉडल की स्थिति के साथ कैसे तालमेल रखते हैं?

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

पर कैसे? MVC पैटर्न मॉडल को उस जानकारी की एक नई प्रतिलिपि को दृश्य परत में धकेलने से रोकता है। हेक, यह मॉडल को दृश्य को एक संदेश भेजने की अनुमति भी नहीं देता है कि उसका राज्य बदल गया है।

हां तकरीबन। ठीक है, मॉडल परत को अन्य परतों से सीधे बात करने की अनुमति नहीं है, क्योंकि ऐसा करने के लिए उन परतों के बारे में कुछ पता होना चाहिए, और एमवीसी नियमों का पालन करता है। हालांकि, अगर एक जंगल में एक पेड़ गिरता है और कोई भी उसे सुनने के लिए आसपास नहीं होता है, तो क्या यह एक आवाज़ करता है?

आप जो उत्तर देखते हैं, वह एक सूचना प्रणाली स्थापित करना है, एक जगह के साथ मॉडल परत प्रदान करना यह विशेष रूप से नो-वन की घोषणा कर सकता है कि उसने कुछ दिलचस्प किया है। अन्य परतें उस अधिसूचना प्रणाली के साथ श्रोताओं को उन घोषणाओं को सुनने के लिए पोस्ट कर सकती हैं, जिनकी वे वास्तव में रुचि रखते हैं। मॉडल परत को किसी के बारे में कुछ भी जानने की जरूरत नहीं है कि कौन सुन रहा है (या भले ही कोई भी सब सुन रहा हो!)। यह सिर्फ एक घोषणा पोस्ट करता है और फिर इसके बारे में भूल जाता है। और अगर कोई भी उस घोषणा को सुनता है और ऐसा महसूस करता है कि वह कुछ कर रहा है - जैसे कुछ नए डेटा के लिए मॉडल पूछना तो वह अपने ऑन-स्क्रीन डिस्प्ले को अपडेट कर सकता है - फिर महान। मॉडल सिर्फ यह सूचीबद्ध करता है कि वह अपने एपीआई परिभाषा के हिस्से के रूप में क्या सूचनाएं भेजता है; और जो कोई और उस ज्ञान के साथ करता है, वह उनके ऊपर है।

MVC संरक्षित है, और हर कोई खुश है। आपका एप्लिकेशन ढांचा अच्छी तरह से एक अंतर्निहित सूचना प्रणाली प्रदान कर सकता है, या आप अपना स्वयं का लिख ​​सकते हैं यदि नहीं ('पर्यवेक्षक पैटर्न' देखें)।

...

वैसे भी, उम्मीद है कि मदद करता है। एक बार जब आप एमवीसी के पीछे की प्रेरणाओं को समझ लेते हैं, तो जिन कारणों से चीजों को जिस तरह से शुरू किया जाता है, वह तब भी समझ में आता है, जब पहली नजर में - वे जरूरत से ज्यादा जटिल लगते हैं।

चीयर्स,

है


कैसे MVVM और MVCS के बारे में, मैंने आपके MVC का जवाब सॉफ्टवेयरइंजीनियरिंग.स्टैकएक्सचेंज.
com

86

MVC ज्यादातर एक buzzword है।

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

MVC वेब अनुप्रयोगों का वर्णन करने के लिए कभी नहीं था।
न ही आधुनिक ऑपरेटिंग सिस्टम, न ही भाषाएँ।
(जिनमें से कुछ ने वास्तव में 1979 की परिभाषा को बेमानी बना दिया)

इसे बनाया गया था। और यह काम नहीं किया।

अब हम एक अश्लील वेब-एमबीसी हाइब्रिड के साथ काम करते हैं, जो अपनी भयंकर चर्चा की स्थिति, बीमार परिभाषा और अर्ध-अनपढ़-प्रोग्रामर को एक लक्ष्य जनसांख्यिकीय के रूप में, सामान्य रूप से सॉफ्टवेयर पैटर्न के लिए एक बहुत बुरा प्रचार करता है।

इस प्रकार, MVC उन लोगों के लिए आसन्न चिंताओं से अलग हो गया जो वास्तव में इसके बारे में बहुत अधिक नहीं सोचना चाहते हैं।

  • डेटा मॉडल एक तरह से नियंत्रित किया जाता है,
  • दृश्य किसी अन्य रूप में,
  • बाकी को केवल "नियंत्रक" नाम दिया गया है और पाठक के विवेक पर छोड़ दिया गया है।

90 के दशक में वेब साइटों / वेब अनुप्रयोगों ने वास्तव में चिंताओं को अलग करने के लिए उपयोग नहीं किया।

वे आंतरायिक स्पेगेटी कोड के भयानक बॉट थे।
यूआई परिवर्तन, रीडिज़ाइन और डेटा पुनर्व्यवस्था अविश्वसनीय रूप से कठिन, महंगी, लंबी, निराशाजनक, बीमार थी।

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

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

जैसा कि यह खड़ा है कि यह सामान्य ज्ञान है , कार्यप्रणाली नहीं ।
यह एक प्रारंभिक बिंदु है , समाधान नहीं ।
यह लोगों को हवा में सांस लेने या क्रंचेज करने के लिए कहने जैसा है , कैंसर का इलाज नहीं है


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

23
It's a fancy word for pre-existing concepts that didn't really need one.और क्या डिजाइन पैटर्न / वास्तुकला उस विवरण के अनुरूप नहीं है?
यानिस डे

8
+1 मूल रूप से इस सामान में से अधिकांश स्पष्ट है एक बार जब आप मूल सिद्धांतों (सामंजस्य, युग्मन, पठनीयता, रूढ़िवादिता, आदि) की समझ रखते हैं और आधुनिक भाषाओं की क्षमताओं के साथ गठबंधन करते हैं।
लोरियन

12
The data model is handled one way, the view in another, the rest is just named "controller"+1
c69

33
-1। मेरी इच्छा है कि मैं सभी मुहावरेदार +1 टिप्पणियों के लिए -10 कर सकूं। इस "स्पष्ट" में से किसी को युग्मन और सामंजस्य के मूल सिद्धांत कैसे दिए गए हैं? MVC, MVP, MVVM, फ़ॉर्म और स्मॉलटॉक के मॉडल सहित UI आर्किटेक्चर लाजिमी है। कुछ कंपनियां कंपोज़िट एप्लिकेशन आर्किटेक्चर को भी चरम पर ले जाती हैं, जैसे कि WS-CAF में। यह कहने के लिए कि "सामान्य ज्ञान" स्वचालित रूप से आपको MVC में ले जाता है, जिसमें डेसकार्टेस के तथाकथित पानी के रूप में भगवान का प्रमाण है। यह स्पष्ट रूप से है कि आप क्या जानते हैं, लेकिन आपका जवाब या तो अन्य तरीकों की अज्ञानता या आपके स्वयं के क्षितिज का विस्तार करने में असमर्थता दर्शाता है।
Aaronaught

39

इसे परिभाषित करने का सबसे अच्छा तरीका है ट्रिवेव रेन्सकग के मूल लेखन पर जाना , जिन्होंने इसका आविष्कार किया: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-india.html

यह कागज, विशेष रूप से, आमतौर पर निश्चित पाठ माना जाता है: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

मॉडल

मॉडल ज्ञान का प्रतिनिधित्व करते हैं। एक मॉडल एक एकल वस्तु (बल्कि निर्बाध) हो सकती है, या यह वस्तुओं की कुछ संरचना हो सकती है ...

एक ओर मॉडल और उसके भागों के बीच एक-से-एक पत्राचार होना चाहिए, और दूसरी ओर मॉडल के मालिक द्वारा बताई गई दुनिया का प्रतिनिधित्व करना चाहिए। इसलिए एक मॉडल के नोड्स को समस्या के एक पहचानने योग्य हिस्से का प्रतिनिधित्व करना चाहिए।

किसी मॉडल के नोड्स सभी एक ही समस्या के स्तर पर होने चाहिए, यह समस्या-उन्मुख नोड्स (जैसे कैलेंडर अपॉइंटमेंट्स) को कार्यान्वयन विवरण (जैसे पैराग्राफ) के साथ मिश्रित करने के लिए भ्रामक और माना जाता है।

दृश्य

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

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

नियंत्रकों

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

एक नियंत्रक को कभी भी विचारों को पूरक नहीं करना चाहिए, उदाहरण के लिए, उनके बीच तीर खींचकर नोड्स के विचारों को कभी भी कनेक्ट नहीं करना चाहिए।

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

संपादक

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

ध्यान दें कि एक संपादक कनेक्ट किए गए दृश्य के रूपकों के माध्यम से उपयोगकर्ता के साथ संवाद करता है, इसलिए संपादक दृश्य के साथ निकटता से जुड़ा हुआ है। एक नियंत्रक को इसके लिए दृश्य पूछकर एक संपादक की पकड़ मिलेगी - कोई अन्य उपयुक्त स्रोत नहीं है।


11

MVC एक डिज़ाइन पैटर्न है जिसका उपयोग व्यावसायिक तर्क को प्रस्तुति से अलग करने के लिए किया जाता है।

यह इस तथ्य से कई अन्य डिजाइन पैटर्न से अलग है कि यह आमतौर पर सफलतापूर्वक लागू नहीं किया जाता है, लेकिन एक रूपरेखा का आधार है।

जबकि एक रणनीति पैटर्न को लागू करने वाला एप्लिकेशन इसके बारे में सिर्फ एक छोटा विवरण है, यह कहते हुए कि एक वेब ऐप एमवीसी डिजाइन पैटर्न का उपयोग करता है, इसकी वास्तुकला को बहुत परिभाषित करता है


2
यह कड़ाई से उपयोगी नहीं है, एमवीसी पैटर्न को लागू करने के लिए बहुत विशिष्ट आवश्यकताएं हैं जो इसे एमवीपी, एमपी, एमवीवीएम से अलग बनाती हैं। यह उन अन्य प्रस्तुति पैटर्न के लिए एक अलग लक्षित दर्शक भी है।
इयान

8

MVC एक सॉफ्टवेयर डिज़ाइन है जो सिस्टम या सबसिस्टम के निम्नलिखित घटकों को अलग करता है:

  1. मॉडल - आवेदन या इसके घटकों की स्थिति के बारे में डेटा। संशोधन या पहुंच के लिए दिनचर्या शामिल हो सकती है।
  2. देखें - डेटा (मॉडल) की एक व्याख्या। यह केवल एक दृश्य प्रतिनिधित्व तक सीमित है, लेकिन ऑडियो, व्युत्पन्न जानकारी (उदाहरण के लिए किसी अन्य मॉडल ऑब्जेक्ट में पाई गई आँकड़े) आदि हो सकती है, इसके अलावा, एक मॉडल में कई दृश्य हो सकते हैं।
  3. नियंत्रण - मॉडल पर संशोधनों को लागू करने वाले सिस्टम के लिए बाहरी इनपुट संभालता है। नियंत्रण / दृश्य निकटता से संबंधित हो सकता है (UI के मामले में)। हालाँकि, अन्य बाहरी इनपुट (जैसे कि नेटवर्क कमांड) को संसाधित किया जा सकता है जो दृश्य से पूरी तरह से स्वतंत्र हैं।

6

मैं कहूंगा कि एमवीसी एक अवधारणा या समान पैटर्न का परिवार है।

मुझे लगता है कि यह लेख पढ़ने लायक है। मार्टिन फाउलर द्वारा जीयूआई आर्किटेक्चर


5
वह फाउलर लेख उत्कृष्ट है, और हर कोई जो एमवीसी शब्द का उपयोग करता है, उसे पढ़ना चाहिए। दो बिंदु मुझे विशेष रूप से दिलचस्प लगते हैं कि GUI में MVC शब्द का मूल उपयोग वेब फ्रेमवर्क में उपयोग करने के लिए अलग है, और यह कि GUIs में, व्यू और कंट्रोलर के बीच का अलगाव अनुमानित से कम उपयोगी पाया गया।
टॉम एंडरसन

3

सबसे पहले, आपको यह निर्धारित करना होगा कि प्रश्न पूछने वाला कौन है, और वह किस प्रकार का उत्तर ढूंढ रहा है। आप इस प्रश्न का उत्तर किसी अन्य प्रश्न के साथ देते हैं, जैसे "किस अर्थ में?"

आप पूछ सकते हैं कि क्या वे सामान्य रूप से MVC का उल्लेख कर रहे हैं, MVC का एक विशेष कार्यान्वयन (यानी asp.net MVC, स्प्रिंग MVC, smalltalk MVC, आदि ..), यह तकनीकी रूप से क्या है, यह क्या है, यह परोपकारी है (हाँ, यह है) दर्शन भी), आदि।

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

एक अच्छा, सरल उत्तर है:

एमवीसी एक सॉफ्टवेयर यूजर इंटरफेस आर्किटेक्चर है, जिसका उपयोग संरचनात्मक और व्यवहार संबंधी चिंताओं को दूर करने के लिए किया जाता है ताकि अधिक रख-रखाव वाले सॉफ़्वेयर की सुविधा हो सके।

तुम भी कह सकते हो:

मॉडल से नियंत्रक से दृश्य को अलग करके, यह उनकी जिम्मेदारियों के आधार पर घटकों के अलगाव को प्रोत्साहित करता है। सिद्धांत रूप में, और आमतौर पर व्यवहार में, यह सिस्टम के विभिन्न हिस्सों को सह-मेलिंग से रोकने और अधिक जटिल सिस्टम बनाने के द्वारा स्थिरता में सुधार करने में मदद करता है।

लेकिन, अंत में, आपको इस बात पर निर्णय दिया जाएगा कि क्या आप उस उत्तर को देते हैं जिसकी वे अपेक्षा कर रहे हैं। समस्या का एकमात्र समाधान यह पता लगाना है कि वे किस तरह के उत्तर की उम्मीद कर रहे हैं।


2

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

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

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

मान लीजिए कि मेरे पास एक वर्ग व्यक्ति है जिसमें तीन गुण हैं: नाम, पता, आयु। मेरे XML परिभाषित लेआउट में उपयोगकर्ता इनपुट के लिए 3 फ़ील्ड हैं: नाम, पता, आयु। मेरी गतिविधि उपयोगकर्ता इनपुट से तीन मान लेती है, एक नया व्यक्ति ऑब्जेक्ट बनाता है और उस पर कुछ विधि लागू करता है जो जानता है कि कुछ व्यक्ति-विशेष तर्क को कैसे संभालना है। ये लो। मॉडल-व्यू-नियंत्रक।


1

मैं हमेशा उन्हें यह बताकर शुरू करता हूं कि पैटर्न कुछ नया नहीं है और कई वर्षों से आसपास है ... इस बिंदु पर वे मुझे एक जिज्ञासु रूप देते हैं और बीएएम !, वे झुके हुए हैं:

और फिर मैं पिछले उत्तरों की तरह विभिन्न बिंदुओं के बारे में बहुत बात करूंगा, लेकिन मुझे लगता है कि इसका संदर्भ प्रासंगिक होना चाहिए, जैसा कि जेबी किंग ने कहा, एएसपी.नेट एमवीसी आदि।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.