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




design-patterns model-view-controller (16)

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

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

https://code.i-harness.com


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

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

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

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

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

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

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

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

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

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

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

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

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

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

प्रस्तुति मॉडल और अलग-अलग प्रस्तुति पैटर्न के बारे में WPF (पूर्व प्रिज्म) के लिए समग्र अनुप्रयोग मार्गदर्शन में एक अनुभाग के बारे में एक MSDN लेख है


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

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

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

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


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

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

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

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


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

MVP में आप कई प्रकार के प्रेजेंटर्स के साथ काम करने के लिए एक सिंगल व्यू और अलग-अलग मल्टीपल व्यूज के साथ एक सिंगल प्रेजेंटर काम कर सकते हैं।

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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

MVC

एमवीपी


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

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

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

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

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

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

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

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

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



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

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

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

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

अधिक Reference


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

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

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

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

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

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

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

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

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

MVC पैटर्न

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

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

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

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

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

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


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

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

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

आशा है कि यह बेहतर मदद करता है।



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

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


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


  • एमवीपी = मॉडल-व्यू-प्रस्तोता
  • MVC = मॉडल-व्यू-नियंत्रक

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




glossary