एमवीपी और एमवीसी क्या हैं और क्या अंतर है?

Question

उपयोगकर्ता के निर्माण के राड (ड्रैग-ड्रॉप और कॉन्फ़िगर) से परे देखने पर , कई उपकरण आपको प्रोत्साहित करते हैं कि आप मॉडल-व्यू-कंट्रोलर , मॉडल-व्यू-प्रस्तोता और मॉडल-व्यू-व्यूमॉडल नामक तीन डिज़ाइन पैटर्न के पार आने की संभावना रखते हैं । मेरे प्रश्न के तीन भाग हैं:

1. ये पैटर्न किन मुद्दों को संबोधित करते हैं?
2. वे समान कैसे हैं?
3. वे कैसे अलग हैं?

Comments

mvc.givan.se/#mvp

— givanse 16

IDK, लेकिन माना जाता है कि मूल MVC के लिए, इसका उपयोग छोटे में किया जाना था। प्रत्येक बटन, लेबल, आदि का अपना दृष्टिकोण और नियंत्रक वस्तु थी, या कम से कम अंकल बॉब का दावा है। मुझे लगता है कि वह स्मॉलटाक के बारे में बात कर रहे थे। YouTube पर उनकी बातचीत देखें, वे आकर्षक हैं।

— still_dreaming_1

MVP दृश्य-नियंत्रक को एक दृश्य और एक प्रस्तुतकर्ता में विभाजित करके अप्रत्यक्ष की एक अतिरिक्त परत जोड़ता है ...

— the_prole

मुख्य अंतर यह है कि MVC में कंट्रोलर मॉडल से व्यू तक कोई डेटा पास नहीं करता है। यह केवल मॉडल से डेटा प्राप्त करने के लिए दृश्य को सूचित करता है। हालांकि, एमवीपी में, व्यू और मॉडल के बीच कोई संबंध नहीं है। प्रस्तुतकर्ता स्वयं ही मॉडल से आवश्यक कोई भी डेटा प्राप्त करता है और इसे दिखाने के लिए दृश्य में भेजता है। सभी आर्किटेक्चर पैटर्न में एंड्रॉइड के नमूने के साथ यह अधिक है: digigene.com/category/android/android-altecture

— अली नेम

उन्हें आर्किटेक्चरल पैटर्न कहा जाता है न कि पैटर्न पैटर्न । यदि आप अंतर जानना चाहते हैं, तो इसे देखें

— हसन अल-हेफनावी

Answer 1

मॉडल-व्यू-प्रस्तुतकर्ता

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

एमवीपी वेब फॉर्म में अलग प्रस्तुति प्राप्त करने के लिए एक बहुत ही स्वाभाविक पैटर्न है। कारण यह है कि व्यू हमेशा ASP.NET रनटाइम द्वारा पहले बनाया जाता है। आप दोनों वेरिएंट के बारे में अधिक जानकारी प्राप्त कर सकते हैं ।

दो प्राथमिक रूपांतर

निष्क्रिय दृश्य: दृश्य जितना संभव हो उतना गूंगा है और इसमें लगभग शून्य तर्क हैं। प्रस्तुतकर्ता एक मध्य व्यक्ति है जो दृश्य और मॉडल से बात करता है। व्यू और मॉडल एक दूसरे से पूरी तरह से परिरक्षित हैं। मॉडल घटनाओं को बढ़ा सकता है, लेकिन प्रस्तुतकर्ता दृश्य को अपडेट करने के लिए उनकी सदस्यता लेता है। पैसिव व्यू में कोई डायरेक्ट डेटा बाइंडिंग नहीं है, इसके बजाय व्यू सेटर गुण को उजागर करता है जिसे प्रस्तुतकर्ता डेटा सेट करने के लिए उपयोग करता है। सभी राज्य प्रस्तुतकर्ता में प्रबंधित किए जाते हैं और दृश्य नहीं।

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

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

• प्रो: डायटबाइंडिंग का उपयोग करके कोड की मात्रा कम हो जाती है।
• Con: इसमें कम परीक्षण योग्य सतह (डेटा बाइंडिंग के कारण) है, और दृश्य में कम एनकैप्सुलेशन है क्योंकि यह सीधे मॉडल से बात करता है।

मॉडल-व्यू-नियंत्रक

में MVC , नियंत्रक देखें जब आवेदन भार सहित किसी भी कार्रवाई के जवाब में प्रदर्शित करने के लिए जो निर्धारित करने के लिए जिम्मेदार है। यह एमवीपी से भिन्न होता है जहां दृश्य के माध्यम से प्रस्तुतकर्ता के लिए कार्य करता है। एमवीसी में, व्यू में प्रत्येक कार्रवाई एक नियंत्रक के साथ एक कॉल के साथ एक कार्रवाई के साथ संबद्ध होती है। वेब में प्रत्येक क्रिया में एक URL पर दूसरी ओर एक कॉल शामिल होता है जिसमें एक नियंत्रक होता है जो प्रतिक्रिया देता है। एक बार जब नियंत्रक ने अपना प्रसंस्करण पूरा कर लिया है, तो यह सही दृश्य लौटाएगा। आवेदन के पूरे जीवन में यह क्रम जारी रहता है:

    दृश्य में कार्रवाई
        -> कंट्रोलर को कॉल करें
        -> नियंत्रक तर्क
        -> नियंत्रक दृश्य लौटाता है।

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

प्रस्तुति मॉडल

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

प्रस्तुति मॉडल और WPF (पूर्व प्रिज्म) के लिए अलग-अलग प्रस्तुति पैटर्न के बारे में प्रस्तुतीकरण मॉडल के बारे में एक MSDN आलेख है।

Comments

क्या आप कृपया इस वाक्यांश को स्पष्ट कर सकते हैं? यह एमवीपी से भिन्न होता है जहां दृश्य के माध्यम से प्रस्तुतकर्ता के लिए कार्य करता है। एमवीसी में, व्यू में प्रत्येक कार्रवाई एक नियंत्रक के साथ एक कॉल के साथ एक कार्रवाई के साथ संबद्ध होती है। मेरे लिए, यह एक ही बात की तरह लगता है, लेकिन मुझे यकीन है कि आप कुछ अलग बता रहे हैं।

— Panzercrisis

@Panzercrisis मुझे यकीन नहीं है कि यह क्या लेखक का मतलब है, लेकिन यह वही है जो मुझे लगता है कि वे कहने की कोशिश कर रहे थे। इस उत्तर की तरह - stackoverflow.com/a/2068/74556 उल्लेख, MVC में, नियंत्रक विधियाँ व्यवहार पर आधारित हैं - दूसरे शब्दों में, आप एक ही नियंत्रक के लिए कई विचार (लेकिन एक ही व्यवहार) मैप कर सकते हैं। एमवीपी में, प्रस्तुतकर्ता को दृश्य के करीब युग्मित किया जाता है, और आमतौर पर एक मैपिंग में परिणाम होता है जो एक-से-एक के करीब होता है, अर्थात इसके संबंधित प्रस्तुतकर्ता की विधि के लिए एक दृश्य कार्रवाई मानचित्र। आप आम तौर पर दूसरे प्रस्तोता की (किसी अन्य दृश्य से) विधि के लिए किसी अन्य दृश्य के कार्यों को मैप नहीं करेंगे।

— डस्टिन केंडल

ध्यान दें कि MVC अक्सर वेब-फ्रेमवर्क द्वारा उपयोग किया जाता है Laravel, जहां प्राप्त URL अनुरोध (शायद उपयोगकर्ताओं द्वारा किए गए) द्वारा नियंत्रित किए जाते हैं Controllerऔर Viewग्राहक द्वारा भेजे गए HTML को भेजा जाता है - इसलिए, बैकएंडView का एक हिस्सा है और उपयोगकर्ता इसे कभी भी सीधे एक्सेस नहीं कर सकता है, और यदि आप इसके विपरीत कहीं भी अनुभव करते हैं तो विचार करें कि एमवीसी-एक्सटेंशन (या यहां तक ​​कि उल्लंघन) के रूप में। @Panzercrisis, यह (जैसे कि OS में उपयोग किया जाता है ) से भिन्न होता है, जहाँ और उपयोगकर्ता की सीधी पहुँच होती है । MVPAndroidactions route through the View to the PresenterView

— टॉप-मास्टर

Answer 2

यह इन डिज़ाइन पैटर्न के कई वेरिएंट का ओवरसिप्लाइज़ेशन है, लेकिन यह मैं दोनों के बीच के अंतर के बारे में सोचना पसंद करता हूं।

MVC

एमवीपी

Comments

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

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

— फुन्गेबॉब

एमवीसी का उदाहरण गलत है; विचारों और नियंत्रकों के बीच एक सख्त 1: 1 संबंध है। परिभाषा के अनुसार, एक नियंत्रक मॉडल के लिए घटनाओं का उत्पादन करने और एकल नियंत्रण के लिए एक जैसे देखने के लिए मानव हावभाव इनपुट की व्याख्या करता है। अधिक सरल रूप से, MVC केवल व्यक्तिगत विजेट के साथ उपयोग के लिए अभिप्रेत था। एक विजेट, एक दृश्य, एक नियंत्रण।

— सैमुअल ए। फाल्वो II

@ सैमुअल.एफ़ल्वोआई हमेशा नहीं, एक है: ASP.NET MVC में नियंत्रकों और विचारों के बीच कई: stackoverflow.com/questions/1673301/…

— 17

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

— सैमुअल ए। फाल्वो II

Answer 3

मैंने कुछ समय पहले इस बारे में ब्लॉग किया था, टॉड स्नाइडर की उत्कृष्ट पोस्ट पर दोनों के बीच के अंतर पर उद्धृत :

यहाँ पैटर्न के बीच महत्वपूर्ण अंतर हैं:

एमवीपी पैटर्न

• मॉडल के मुकाबले दृश्य अधिक शिथिल है। प्रस्तुतकर्ता मॉडल को दृश्य में बांधने के लिए जिम्मेदार है।
• यूनिट टेस्ट के लिए आसान क्योंकि दृश्य के साथ बातचीत एक इंटरफेस के माध्यम से है
• आमतौर पर एक से एक प्रस्तुतकर्ता मानचित्र देखें। जटिल दृश्यों में बहु प्रस्तुतकर्ता हो सकते हैं।

MVC पैटर्न

• नियंत्रक व्यवहार पर आधारित होते हैं और इन्हें विचारों में साझा किया जा सकता है
• यह निर्धारित करने के लिए जिम्मेदार हो सकता है कि किस दृश्य को प्रदर्शित किया जाए

यह मेरे द्वारा खोजे जा सकने वाले वेब पर सबसे अच्छा विवरण है।

Comments

मुझे समझ में नहीं आता है कि कैसे दृश्य को मॉडल के अधिक या कम निकटता से युग्मित किया जा सकता है जब दोनों मामलों में पूरे बिंदु को पूरी तरह से उन्हें अलग करना है। मैं यह नहीं कह रहा हूं कि आपने कुछ गलत कहा है - सिर्फ इस उलझन में कि आपका क्या मतलब है।

— बिल K

@pst: एमवीपी के साथ यह वास्तव में 1 दृश्य = 1 प्रस्तुतकर्ता है। MVC के साथ, नियंत्रक कई विचारों को नियंत्रित कर सकता है। वास्तव में यही है। "टैब" मॉडल के साथ सभी टैब के लिए एक नियंत्रक होने का विरोध करने के रूप में प्रत्येक टैब में अपने स्वयं के प्रस्तुतकर्ता होने की कल्पना करें।

— जॉन लिमजप

मूल रूप से दो प्रकार के नियंत्रक होते हैं: एक जिसे आपने कई दृश्यों में साझा करने के लिए कहा था, और वे जो विशिष्ट हैं, मुख्य रूप से साझा नियंत्रक के इंटरफेस को अपनाने के लिए बनाए गए हैं।

— Acsor

@JonLimjap वैसे भी एक दृश्य से क्या मतलब है? आईओएस प्रोग्रामिंग के संदर्भ में, क्या यह एक-स्क्रीन वाला है? क्या यह एमवीसी की तरह एमवीपी की तरह आईओएस के नियंत्रक को अधिक बनाता है? (दूसरी तरफ आप प्रति स्क्रीन में कई iOS कंट्रोलर भी रख सकते हैं)

— Huggie

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

— राख

Answer 4

यहाँ ऐसे चित्र हैं जो संचार प्रवाह का प्रतिनिधित्व करते हैं

Comments

मेरे पास MVC आरेख के बारे में एक प्रश्न है। मुझे वह हिस्सा नहीं मिलता है, जहां से दृश्य डेटा प्राप्त करने के लिए निकलता है। मुझे लगता है कि नियंत्रक को आवश्यक डेटा के साथ दृश्य को अग्रेषित करना होगा।

— ब्रायन रिज़ो

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

— जोनाथन

मुझे पता है कि यह एक पुराना उत्तर है - लेकिन क्या कोई @JonathanLeaders बिंदु पर प्रतिक्रिया दे सकता है? जब तक आप कुछ बहुत ही अनोखा कोडिंग नहीं करते, तब तक मैं एक विफ़ॉर्म बैकग्राउंड से आता हूं, जब आप यूआई / व्यू पर क्लिक करते हैं तो किसी भी चीज़ से पहले उस क्लिक का ज्ञान प्राप्त करते हैं। कम से कम, जहां तक ​​मुझे पता है?

— रोब पी।

@RobP। मुझे लगता है कि इस प्रकार के चार्ट हमेशा बहुत जटिल या बहुत सरल होते हैं। एमवीपी चार्ट का इमोजी एमवीसी एप्लिकेशन के लिए भी सही है। भाषाओं के फीचर्स (डेटा बाइंडिंग / ऑब्जर्वर) के आधार पर भिन्नताएं हो सकती हैं, लेकिन अंत में यह विचार एप्लिकेशन के डेटा / लॉजिक से व्यू को डिकम्प्लस करना है।

— लुका फ्यूलियर

@JonathanLeaders लोगों के मन में वास्तव में अलग-अलग चीजें हैं जब वे "एमवीसी" कहते हैं। इस चार्ट को बनाने वाले व्यक्ति के दिमाग में संभवतः क्लासिक वेब MVC था, जहां "उपयोगकर्ता इनपुट" HTTP अनुरोध हैं, और "उपयोगकर्ता को दिया गया दृश्य" एक प्रदान किया गया HTML पृष्ठ है। तो उपयोगकर्ता और दृश्य के बीच कोई भी बातचीत शास्त्रीय वेब एमवीसी ऐप के एक लेखक के दृष्टिकोण से "अस्तित्व नहीं" है।

— क्यूबप्लप 42

Answer 5

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

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

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

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

Comments

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

— माइकल

मैं MVP को एक एंटी-पैटर्न नहीं कहूँगा , जैसा कि बाद में ".. बाकी [एमवीपी सहित] [MVC] .. के अलग-अलग स्वाद हैं, जो कि मतलब होगा कि यदि MVP एक पैटर्न-विरोधी था, तो MVC था ... यह एक अलग ढांचे के दृष्टिकोण के लिए सिर्फ एक स्वाद है। (अब, कुछ विशिष्ट एमवीपी कार्यान्वयन अलग-अलग कार्यों के लिए कुछ विशिष्ट एमवीसी कार्यान्वयनों की तुलना में कम या अधिक वांछनीय हो सकते हैं ...)

@Quibblsome: "मुझे व्यक्तिगत रूप से लगता है कि एमवीपी को केवल हाल ही में एक आकर्षक शब्द के रूप में फिर से पेश किया गया है जो या तो अर्थपूर्ण बड़े लोगों के बीच तर्कों को कम करने के लिए है जो तर्क देते हैं कि क्या वास्तव में एमवीसी है या नहीं [...] मेरी पुस्तकों में इन कारणों में से कोई भी इसके अस्तित्व को नहीं मानता है। अलग डिजाइन पैटर्न। ” । यह अलग बनाने के लिए पर्याप्त है। MVP में, दृश्य पूर्वनिर्धारित इंटरफ़ेस को पूरा करने वाला कुछ भी हो सकता है (MVP में दृश्य एक स्टैंडअलोन घटक है)। एमवीसी में, नियंत्रक एक विशेष दृष्टिकोण के लिए बनाया गया है (यदि संबंध की धमनी किसी को महसूस कर सकती है कि दूसरे शब्द के लायक है)।

— हिबू

@ Hibou57, MVC को इंटरफ़ेस के रूप में संदर्भित करने या कई अलग-अलग दृश्यों के लिए एक सामान्य नियंत्रक बनाने से रोकने के लिए कुछ भी नहीं है।

— Quibblesome

सैमुअल कृपया स्पष्ट करें कि आप किस बारे में बात कर रहे हैं। जब तक आप मुझे टीम का इतिहास नहीं बताएंगे कि "MVC" का आविष्कार किया है, तब मैं आपके पाठ के बारे में अविश्वसनीय रूप से संदिग्ध हूं। यदि आप सिर्फ WinForm के बारे में बात कर रहे हैं, तो काम करने के अन्य तरीके हैं और मैंने WinForm प्रोजेक्ट बनाए हैं जहाँ कंट्रोल बाइंडिंग को कंट्रोलर द्वारा प्रबंधित किया जाता है, न कि "व्यक्तिगत नियंत्रण" पर।

— क्विबल्सम Qu

Answer 6

MVP: दृश्य प्रभारी है।

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

MVC: नियंत्रक प्रभारी है।

नियंत्रक को किसी घटना / अनुरोध के आधार पर बनाया या एक्सेस किया जाता है। नियंत्रक तब उपयुक्त दृश्य बनाता है और दृश्य को और कॉन्फ़िगर करने के लिए मॉडल के साथ इंटरैक्ट करता है। यह उबलता है: नियंत्रक बनाता है और दृश्य का प्रबंधन करता है; नियंत्रक के लिए दृश्य दास है। व्यू कंट्रोलर के बारे में नहीं जानता है।

Comments

"व्यू कंट्रोलर के बारे में नहीं जानता है।" मुझे लगता है कि आपका मतलब है कि दृश्य का मॉडल के साथ सीधे संपर्क नहीं है?

— लोटस नोट्स 7

दृश्य को आइटर एक में मॉडल के बारे में कभी नहीं जानना चाहिए।

— ब्रायन लेहि

@Brian: "देखें, ज्यादातर मामलों में, यह प्रस्तुतकर्ता बनाता है।" । मैंने ज्यादातर विपरीत देखा, प्रस्तुतकर्ता के साथ मॉडल और दृश्य दोनों को लॉन्च किया। ठीक है, दृश्य प्रस्तुतकर्ता को भी लॉन्च कर सकता है, लेकिन यह बिंदु वास्तव में सबसे विशिष्ट नहीं है। जीवनकाल के दौरान जो सबसे अधिक होता है वह मायने रखता है।

— हिबॉ57

आप आगे व्याख्या करने के लिए अपने उत्तर को संपादित करना चाह सकते हैं: चूँकि व्यू कंट्रोलर के बारे में नहीं जानता है, उपयोगकर्ता क्रियाएँ कैसे होती हैं, जो स्क्रीन पर उपयोगकर्ता द्वारा देखे जाने वाले performed विज़ुअल ’तत्वों पर की जाती हैं (यानी व्यू), नियंत्रक को संप्रेषित ...

— ऐश

Answer 7

MVC (मॉडल दृश्य नियंत्रक)

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

एमवीपी (मॉडल देखें प्रस्तुतकर्ता)

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

अधिक संदर्भ के लिए

Comments

लेकिन MVPपैटर्न में, जब पहली बार आवेदन लोड होता है, तो क्या प्रस्तोता पहले दृश्य को लोड करने के लिए जिम्मेदार नहीं है? उदाहरण के लिए, जब हम फेसबुक एप्लिकेशन को लोड करते हैं, तो क्या लॉगिन पेज लोड करने के लिए प्रस्तुतकर्ता जिम्मेदार नहीं है?

— सांप

MVC में मॉडल से व्यू तक का लिंक? आप इस लिंक को देखते हुए यह समझाने के लिए अपने उत्तर को संपादित करना चाहते हैं कि यह इसे 'डिकूप्ड' प्रणाली कैसे बनाता है। संकेत: आपको यह कठिन लग सकता है। इसके अलावा, जब तक आपको नहीं लगता कि पाठक खुशी से स्वीकार करेंगे कि वे अपने पूरे जीवन को गलत मान रहे हैं, आप इस बात पर विस्तार से विचार कर सकते हैं कि उपयोगकर्ता स्क्रीन पर 'दृश्य' तत्वों के साथ बातचीत करने के बावजूद एमवीसी में नियंत्रक के माध्यम से पहले क्यों जाते हैं (अर्थात देखें), कुछ सार परत नहीं जो प्रसंस्करण करने के पीछे बैठती है।

— राख

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

— मेगामैनएक्स

मैं ऐश और मेगामैनएक्स से सहमत हूं। MVC आरेख में, तीर दृश्य से मॉडल (या ViewModel, या DTO) की ओर होना चाहिए, मॉडल से दृश्य तक नहीं; क्योंकि मॉडल दृश्य के बारे में नहीं जानता है, लेकिन दृश्य मॉडल के बारे में जान सकता है।

— जोब फ्लैगा

Answer 8

प्रश्न के कई उत्तर हैं, लेकिन मुझे लगा कि दोनों की तुलना करते हुए स्पष्ट रूप से कुछ सरल उत्तर की आवश्यकता है। यहाँ एक उपयोगकर्ता द्वारा MVP और MVC ऐप में एक मूवी का नाम खोजे जाने की चर्चा है।

उपयोगकर्ता: क्लिक करें क्लिक करें ...

देखें : वह कौन है? [ एमवीपी | MVC ]

उपयोगकर्ता: मैंने बस खोज बटन पर क्लिक किया है ...

देखें : ठीक है, एक सेकंड पर पकड़ ...। [ एमवीपी | MVC ]

( प्रस्तुतकर्ता कॉलिंग देखें । नियंत्रक …) [ MVP | MVC ]

देखें : अरे प्रस्तुतकर्ता | नियंत्रक , उपयोगकर्ता ने केवल खोज बटन पर क्लिक किया है, मुझे क्या करना चाहिए? [ एमवीपी | MVC ]

प्रस्तुतकर्ता | नियंत्रक : अरे देखिए , क्या उस पृष्ठ पर कोई खोज शब्द है? [ एमवीपी | MVC ]

देखें : हाँ, ... यहाँ यह है ... "पियानो" [ MVP | MVC ]

प्रस्तुतकर्ता : धन्यवाद देखें , ... इस बीच मैं मॉडल पर खोज शब्द देख रहा हूं , कृपया उसे / उसे एक प्रगति बार दिखाएं [ MVP | MVC ]

( प्रस्तुतकर्ता | नियंत्रक मॉडल को बुला रहा है ...) [ एमवीपी | MVC ]

प्रस्तुतकर्ता | नियंत्रक : अरे मॉडल , क्या आपके पास इस खोज शब्द का कोई मेल है ?: "पियानो" [ MVP | MVC ]

मॉडल : अरे प्रस्तुतकर्ता | नियंत्रक , मुझे जांचने दें… [ MVP | MVC ]

( मॉडल फिल्म डेटाबेस के लिए एक प्रश्न बना रहा है ...) [ एमवीपी | MVC ]

( कुछ समय बाद ... )

-------------- यह वह जगह है जहां MVP और MVC विचलन शुरू करते हैं ---------------

आदर्श : मुझे आपके लिए एक सूची मिली है, प्रस्तुतकर्ता , यहाँ यह JSON में है "[{" नाम ":" पियानो शिक्षक "," वर्ष ": 2001}, {" नाम ":" पियानो "," वर्ष ": 1993} ] "[ एमवीपी ]

मॉडल : कुछ परिणाम उपलब्ध है, नियंत्रक । मैंने अपने उदाहरण में एक फ़ील्ड चर बनाया है और इसे परिणाम के साथ भर दिया है। यह नाम है "searchResultsList" [ MVC ]

( प्रस्तुतकर्ता | नियंत्रक धन्यवाद मॉडल और करने के लिए वापस हो जाता है दृश्य ) [ एमवीपी | MVC ]

प्रस्तुतकर्ता : इंतजार कर के लिए धन्यवाद देखें , मैं तुम्हारे लिए परिणाम मिलान की एक सूची मिल गया है और एक आकर्षक स्वरूप में उन्हें व्यवस्था की: [ "पियानो टीचर 2001", "पियानो 1993"]। कृपया इसे उपयोगकर्ता को एक ऊर्ध्वाधर सूची में दिखाएं। कृपया अब प्रगति बार को छिपाएँ [ MVP ]

नियंत्रक : इंतजार कर के लिए धन्यवाद देखें , मैं कहा है मॉडल अपनी खोज क्वेरी के बारे में। यह कहता है कि यह मिलान परिणामों की एक सूची पाया गया है और उन्हें अपने उदाहरण के अंदर "searchResultsList" नामक एक चर में संग्रहीत किया है। आप इसे वहां से प्राप्त कर सकते हैं। कृपया अब प्रगति बार को छिपाएँ [ MVC ]

देखें : बहुत बहुत धन्यवाद प्रस्तुतकर्ता [ एमवीपी ]

दृश्य : धन्यवाद "नियंत्रक" [ एमवीसी ] (अब दृश्य खुद से सवाल कर रहा है: मुझे मॉडल से उपयोगकर्ता को प्राप्त होने वाले परिणाम कैसे पेश करने चाहिए? क्या फिल्म का उत्पादन वर्ष पहले या आखिरी आना चाहिए ...? एक ऊर्ध्वाधर या क्षैतिज सूची में हो? ...)

यदि आप रुचि रखते हैं, तो मैं यहां Github रेपो के साथ ऐप आर्किटेक्चरल पैटर्न (MVC, MVP, MVVP, क्लीन आर्किटेक्चर, ...) से संबंधित लेखों की एक श्रृंखला लिख ​​रहा हूं । भले ही नमूना एंड्रॉइड के लिए लिखा गया हो, अंतर्निहित सिद्धांतों को किसी भी माध्यम पर लागू किया जा सकता है।

Comments

मूल रूप से आप जो कहने की कोशिश कर रहे हैं, वह यह है कि व्यू लॉजिक को माइक्रोप्रोमाइज करता है? तो यह क्या होता है और कैसे विचारों को प्रस्तुत करके दृश्य को सुस्त बनाता है?

— रादु

@Radu, नहीं, यह micromanage नहीं करता है, जो कि प्रस्तुतकर्ता को निष्क्रिय या गूंगा बना देता है

— अली नेम

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

— टॉमी एंडरसन

Answer 9

• एमवीपी = मॉडल-व्यू-प्रस्तोता

• MVC = मॉडल-व्यू-नियंत्रक

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

Comments

मॉडल अद्यतन करना। और यह अभी भी एक विघटित प्रणाली है?

— राख

Answer 10

मॉडल-व्यू-नियंत्रक

MVC एक सॉफ्टवेयर एप्लीकेशन के आर्किटेक्चर के लिए एक पैटर्न है। यह अनुप्रयोग तर्क को तीन अलग-अलग हिस्सों में अलग करता है, मॉड्यूलरिटी को बढ़ावा देता है और सहयोग और पुन: उपयोग में आसानी करता है। यह एप्लिकेशन को अधिक लचीला बनाता है और पुनरावृत्तियों का स्वागत करता है। यह एक एप्लिकेशन को निम्नलिखित घटकों में अलग करता है:

• डेटा और व्यावसायिक तर्क को संभालने के लिए मॉडल
• उपयोगकर्ता इंटरफ़ेस और एप्लिकेशन को संभालने के लिए नियंत्रकों
• चित्रमय उपयोगकर्ता इंटरफ़ेस ऑब्जेक्ट्स और प्रस्तुति को संभालने के लिए दृश्य

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

मॉडल-व्यू-प्रस्तुतकर्ता

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

यदि आप सरल कार्यान्वयन के साथ एक नमूना देखना चाहते हैं तो कृपया इस GitHub पोस्ट को देखें

किसी डेटाबेस से उपयोगकर्ताओं की सूची को क्वेरी करने और प्रदर्शित करने का एक ठोस वर्कफ़्लो इस तरह काम कर सकता है:

क्या है अंतर के बीच MVC और एमवीपी पैटर्न?

MVC पैटर्न

• नियंत्रक व्यवहार पर आधारित होते हैं और इन्हें विचारों में साझा किया जा सकता है

• यह निर्धारित करने के लिए जिम्मेदार हो सकता है कि कौन सा दृश्य प्रदर्शित करना है (फ्रंट कंट्रोलर पैटर्न)

एमवीपी पैटर्न

• मॉडल के मुकाबले दृश्य अधिक शिथिल है। प्रस्तुतकर्ता मॉडल को दृश्य में बांधने के लिए जिम्मेदार है।

• यूनिट टेस्ट के लिए आसान क्योंकि दृश्य के साथ बातचीत एक इंटरफेस के माध्यम से है

• आमतौर पर एक से एक प्रस्तुतकर्ता मानचित्र देखें। जटिल दृश्यों में बहु प्रस्तुतकर्ता हो सकते हैं।

Comments

nah, mvc में दृश्य और मॉडल के बीच कोई सीधा संबंध नहीं है। आपका डायग्राम गलत है।

— .zgür

Answer 11

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

पैसिव व्यू का उपयोग करते समय, आपका दृश्य आम तौर पर ठीक से अनूठे इंटरफ़ेस को कार्यान्वित करता है, जिसमें कम या ज्यादा सीधे यूआई विजेट के मानचित्रण होते हैं। उदाहरण के लिए, आपके पास नाम और पते जैसी संपत्तियों के साथ एक ICustomerView हो सकता है।

आपका कार्यान्वयन कुछ इस तरह दिख सकता है:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

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

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

एमवीपी का तीसरा "स्वाद" (या कोई व्यक्ति शायद इसे अलग पैटर्न कहेगा) प्रेजेंटेशन मॉडल (या कभी-कभी मॉडल-व्यू-व्यूमॉडल के लिए संदर्भित होता है)। एमवीपी की तुलना में आप एम और पी को एक वर्ग में "मर्ज" करते हैं। आपके पास आपकी ग्राहक वस्तु है, जो आपके UI विजेट्स से बँधा हुआ डेटा है, लेकिन आपके पास अतिरिक्त यूआई-स्पेशल क्षेत्र भी हैं जैसे "IsButtonEnabled", या "IsReadOnly", आदि।

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

मैंने YouCard Re-विज़िट पर सिल्वरलाइट के संदर्भ में Model-View-ViewModel पैटर्न के बारे में भी ब्लॉग किया है: ViewModel पैटर्न को लागू करना ।

Answer 12

वे प्रत्येक समस्याओं को अलग-अलग संबोधित करते हैं और यहां तक ​​कि नीचे की तरह कुछ करने के लिए एक साथ जोड़ा जा सकता है

यहां एमवीसी, एमवीपी और एमवीवीएम की भी पूरी तुलना है

Comments

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

— फरीद

Answer 13

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

एमवीसी बनाम एमवीपी के बीच मतभेदों के बारे में यहां एक चर्चा है ।

बनाया गया भेद यह है कि एक एमवीसी एप्लिकेशन में पारंपरिक रूप से दृश्य और नियंत्रक मॉडल के साथ बातचीत करते हैं, लेकिन एक दूसरे के साथ नहीं।

एमवीपी डिज़ाइन में प्रस्तुतकर्ता मॉडल का उपयोग करता है और दृश्य के साथ बातचीत करता है।

कहा जा रहा है कि, ASP.NET MVC इन परिभाषाओं द्वारा एक MVP फ्रेमवर्क है, क्योंकि नियंत्रक उस दृश्य को आबाद करने के लिए मॉडल का उपयोग करता है जिसका कोई तर्क नहीं है (बस नियंत्रक द्वारा प्रदान किए गए चर प्रदर्शित करता है)।

शायद MVP से ASP.NET MVC भेद का एक विचार प्राप्त करने के लिए, स्कॉट हंसेलमैन द्वारा इस MIX प्रस्तुति की जाँच करें ।

Comments

एमवीसी और एमवीपी पैटर्न हैं, न कि फ्रेमवर्क। यदि आप ईमानदारी से सोचते हैं, तो वह विषय .NET फ्रेमवर्क के बारे में था, तो यह "इंटरनेट" सुनने और आईई के बारे में सोचने जैसा है।

— tereško

बहुत यकीन है कि जब यह पहली बार 2008 में वापस पूछा गया था, तब से प्रश्न काफी विकसित हो गया है। इसके अलावा, मेरे जवाब पर वापस देख रहे हैं (और यह 4 साल पहले था, इसलिए मेरे पास आपके मुकाबले बहुत अधिक संदर्भ नहीं है) मैं कहूंगा कि मैं आम तौर पर शुरू करता हूं इसके बाद .NET MVC को एक ठोस उदाहरण के रूप में उपयोग करें।

— मैट मिशेल

Answer 14

दोनों पैटर्न को अलग-अलग प्रस्तुति और व्यापार तर्क को अलग करने की कोशिश कर रहे हैं, यूआई पहलुओं से व्यावसायिक तर्क को डिकम्प्लिंग कर रहे हैं

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

दोनों ने TDD को सक्षम और डाउनसाइड और अपसाइड किया।

उनमें से किसी एक को चुनने का निर्णय IMHO के आधार पर किया जाना चाहिए, जिसमें एएसपी नेट वेब फॉर्म वेब विकास के प्रकार में कितना समय लगाया गया हो। अगर कोई खुद को वेब रूपों में अच्छा मानता है, तो मैं सुझाव दूंगा कि एमवीपी। अगर किसी को पेज लाइफ साइकल आदि चीजों में इतना सहज महसूस नहीं होता है तो MVC यहां जाने का एक तरीका हो सकता है।

इस विषय पर अभी तक एक और ब्लॉग पोस्ट लिंक थोड़ा और विवरण दे रहा है

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

Answer 15

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

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

मेरा अनुभव मुझे बताता है कि वेब फॉर्म से एमवीपी और फिर एमवीपी से एमवीसी तक एक टीम को स्थानांतरित करना अपेक्षाकृत आसान है; वेब रूपों से MVC में जाना अधिक कठिन है।

मैं यहां उन लेखों की श्रृंखला की एक कड़ी छोड़ता हूं जो मेरे एक मित्र ने एमवीपी और एमवीसी के बारे में प्रकाशित की हैं।

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

Answer 16

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

MVP में आप कई प्रकार के प्रस्तुतकर्ताओं के साथ काम करने के लिए एक ही दृश्य हो सकते हैं और एक प्रस्तुतकर्ता अलग-अलग कई विचारों के साथ काम कर सकता है।

एमवीपी आमतौर पर किसी प्रकार के बाध्यकारी ढांचे का उपयोग करता है, जैसे कि माइक्रोसॉफ्ट डब्ल्यूपीएफ बाध्यकारी ढांचा या एचटीएमएल 5 और जावा के लिए विभिन्न बाध्यकारी ढांचे।

उन रूपरेखाओं में, यूआई / एचटीएमएल 5 / एक्सएएमएल, इस बात से अवगत है कि प्रत्येक यूआई तत्व प्रदर्शित करने वाले की संपत्ति क्या है, इसलिए जब आप किसी प्रस्तुतकर्ता को एक दृश्य बाँधते हैं, तो दृश्य गुणों की तलाश करता है और जानता है कि उनसे डेटा कैसे और कैसे प्राप्त किया जाए उपयोगकर्ता द्वारा UI में एक मान बदलने पर उन्हें सेट करने के लिए।

इसलिए, यदि उदाहरण के लिए, मॉडल एक कार है, तो प्रस्तुतकर्ता कार प्रस्तुतकर्ता के कुछ प्रकार है, दृश्य के लिए कार गुण (वर्ष, निर्माता, सीटें, आदि) को उजागर करता है। यह दृश्य जानता है कि called कार निर्माता ’नामक पाठ क्षेत्र को प्रस्तुतकर्ता निर्माता संपत्ति प्रदर्शित करने की आवश्यकता है।

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

यह बाध्यकारी ढांचा, यदि आप इसे बंद कर देते हैं, तो यह वास्तव में नियंत्रक है :-)

और इसलिए, आप एमवीपी को एमवीसी के विकास के रूप में देख सकते हैं।

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

निष्कर्ष - एमवीपी और एमवीसी दोनों यूआई पैटर्न के डिकूप्ल हैं, लेकिन एमवीपी आमतौर पर एक बाइंडिंग फ्रेमवर्क का उपयोग करता है जो एमवीसी के नीचे है। THUS MVP MVC की तुलना में एक उच्च वास्तुशिल्प स्तर पर है और MVC के ऊपर एक आवरण पैटर्न है।

Answer 17

मेरा विनम्र संक्षिप्त दृष्टिकोण: एमवीपी बड़े पैमाने पर है, और छोटे तराजू के लिए एमवीसी। MVC के साथ, मुझे कभी-कभी लगता है कि V और C को एक ही अविभाज्य घटक के दो पक्ष दिखाई दे सकते हैं, बल्कि सीधे M से बँधा होता है, और एक अनिवार्य रूप से इस पर गिरता है, जब UI नियंत्रण और बेस विजेट जैसे छोटे पैमानों पर नीचे जाता है। ग्रैन्युलैरिटी के इस स्तर पर, एमवीपी कम समझ में आता है। जब कोई इसके विपरीत बड़े पैमाने पर जाता है, तो उचित इंटरफ़ेस अधिक महत्वपूर्ण हो जाता है, जिम्मेदारियों के असंगत असाइनमेंट के साथ ही, और यहां एमवीपी आता है।

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

Answer 18

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

( लेख में यह भी लिखा गया है कि चाचा बॉब मार्टिन ने अपनी एक वार्ता में कहा था: कि MVC मूल रूप से छोटे UI घटकों के लिए डिज़ाइन किया गया था, सिस्टम की वास्तुकला के लिए नहीं)

Answer 19

एमवीसी के कई संस्करण हैं, यह उत्तर स्मॉलटाक में मूल एमवीसी के बारे में है। संक्षेप में, यह है

यह बात droidcon NYC 2017 - आर्किटेक्चर कंपोनेंट्स के साथ क्लीन ऐप डिज़ाइन इसे स्पष्ट करता है

Comments

MVC में मॉडल को कभी भी दृश्य से सीधे नहीं बुलाया जाता है

— rody

यह एक गलत उत्तर है। गुमराह न हों। जैसा कि @rodi लिखते हैं, व्यू और मॉडल के बीच कोई इंटरैक्शन नहीं है।

— शॉन मेहान

MVC की छवि गलत है या सबसे भ्रामक है, कृपया इस उत्तर पर ध्यान न दें।

— Jay

@ Jay1b आपको क्या लगता है कि MVC "सही" है? यह उत्तर मूल MVC के बारे में है। कई अन्य MVC (जैसे iOS में) को प्लेटफ़ॉर्म के अनुकूल करने के लिए बदल दिया गया था, जैसे कहते हैंUIKit

— onmyway133

तीर का मतलब क्या है?

— problemofficer

Answer 20

अंकल बॉब का यह अच्छा वीडियो है जहां उन्होंने संक्षेप में MVC और MVP को समझाया है ।

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

एमवीसी में, हम विभिन्न परतों को गोंद करने के लिए इंटरफेस (सीमाओं) के माध्यम से बात करते हैं। एक कंट्रोलर हमारे आर्किटेक्चर का प्लग-इन है, लेकिन इसमें ऐसा कोई प्रतिबंध नहीं है कि क्या दिखाया जाए। उस अर्थ में, एमवीपी एक एमवीसी की तरह है जिसमें विचारों की अवधारणा एडेप्टर से अधिक नियंत्रक के लिए सुगम होती है।

मुझे उम्मीद है कि इससे बेहतर मदद मिलेगी।

Comments

अंकल बॉब से महत्वपूर्ण बिंदु: जब मूल रूप से Trygve Reenskaug द्वारा आविष्कार किया गया था, MVC का अर्थ था प्रत्येक विजेट के लिए संपूर्ण रूप नहीं।

— बेसिल बोर्के

Answer 21

आप एक्शन-डोमेन-रिस्पॉन्डर ( ADR ) के बारे में भूल गए ।

जैसा कि ऊपर कुछ ग्राफिक्स में बताया गया है, MVC में मॉडल और व्यू के बीच सीधा संबंध / लिंक है । नियंत्रक पर एक कार्रवाई की जाती है , जो मॉडल पर एक कार्रवाई निष्पादित करेगा । मॉडल में वह क्रिया , दृश्य में एक प्रतिक्रिया को ट्रिगर करेगी । देखें , हमेशा अपडेट जब है मॉडल के राज्य बदल जाता है।

कुछ लोग भूल जाते हैं, कि MVC 70 के दशक के अंत में बनाया गया था , और यह कि वेब केवल 80 के अंत में बनाया गया था "90 के दशक की शुरुआत में"। MVC मूल रूप से वेब के लिए नहीं बनाया गया था, लेकिन इसके बजाय डेस्कटॉप अनुप्रयोगों के लिए, जहां नियंत्रक , मॉडल और व्यू एक साथ मौजूद होंगे।

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

इसके बजाय, एक्शन-डोमेन-रिस्पॉन्डर पर एक नज़र डालें । ADR में, कंट्रोलर को एक एक्शन मिलता है , जो मॉडल / डोमेन में एक ऑपरेशन करेगा । अब तक, वही। अंतर यह है कि यह उस ऑपरेशन की प्रतिक्रिया / डेटा एकत्र करता है, और रेंडर करने के लिए इसे एक उत्तरदाता ( जैसे:)view() को पास करता है। जब एक ही घटक पर एक नई कार्रवाई का अनुरोध किया जाता है , तो नियंत्रक को फिर से बुलाया जाता है, और चक्र खुद को दोहराता है। ADR में, मॉडल / डोमेन और दृश्य ( रेपोनसर की प्रतिक्रिया ) के बीच कोई संबंध नहीं है ।

नोट: विकिपीडिया बताता है कि " प्रत्येक ADR क्रिया, हालांकि, अलग-अलग वर्गों या क्लोजर द्वारा दर्शायी जाती है। " यह जरूरी सच नहीं है। कई कार्य एक ही नियंत्रक में हो सकते हैं, और पैटर्न अभी भी समान है।

MVC एडीआर मॉडल-दृश्य-नियंत्रक कार्रवाई-डोमेन-प्रत्युत्तर

Answer 22

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

Comments

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

— problemofficer

विकिपीडिया पर एमवीसी को देखें, यह ठीक है कि यह कैसे काम करता है।

— क्लाइव जेफ़रीज़

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

— अंडरस्कोर_ड

शब्दांकन में निश्चित रूप से सुधार किया जा सकता है, लेकिन यह सच है कि दृश्य एमवीसी में मॉडल में परिवर्तन की सदस्यता लेता है। मॉडल को MVC में व्यू जानने की आवश्यकता नहीं है।

— १०:५०

धन्यवाद..इसने मेरी बहुत मदद की

— Dvyn Resh

Answer 23

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

Answer 24

एमवीपी

एमवीपी का मतलब है मॉडल - व्यू- प्रस्तोता। यह 2007 की शुरुआत में एक तस्वीर में आया था जहां Microsoft ने स्मार्ट क्लाइंट विंडोज़ एप्लिकेशन पेश किए थे।

एक प्रस्तुतकर्ता MVP में एक पर्यवेक्षी भूमिका के रूप में कार्य कर रहा है जो मॉडल से घटनाओं और व्यावसायिक तर्क को बाध्य करता है।

व्यू इवेंट बाइंडिंग को प्रस्तुतकर्ता से दृश्य इंटरफ़ेस में लागू किया जाएगा।

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

पेशेवरों: दृश्य में केवल यूआई ही नहीं है, न ही लॉजिक्स उच्च स्तर की परीक्षण क्षमता

विपक्ष: इवेंट बाइंडिंग को लागू करते समय बिट कॉम्प्लेक्स और अधिक काम

MVC

एमवीसी का अर्थ है मॉडल-व्यू-कंट्रोलर। बाध्यकारी मॉडल के साथ मॉडल बनाने और विचार प्रस्तुत करने के लिए नियंत्रक जिम्मेदार है।

नियंत्रक सर्जक है और यह तय करता है कि किस दृश्य को प्रस्तुत करना है।

पेशेवरों: एकल जिम्मेदारी सिद्धांत पर जोर उच्च स्तर की परीक्षणशीलता

विपक्ष: कभी-कभी नियंत्रकों के लिए बहुत अधिक कार्यभार, यदि एक ही नियंत्रक में कई विचारों को प्रस्तुत करने का प्रयास करें।