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




model-view-controller user-interface mvp glossary (21)

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

  1. इन पैटर्न का क्या पता है?
  2. वे समान कैसे हैं?
  3. वे कैसे अलग हैं?

Answers

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

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

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

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

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

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

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

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

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

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

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

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

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

  • मॉडल को मॉडल के साथ अधिक ढीला रूप से देखा गया है। प्रस्तुतकर्ता मॉडल को देखने के लिए बाध्यकारी के लिए ज़िम्मेदार है।

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

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


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

एमवीपी में आप एक ही दृश्य देख सकते हैं जिसमें कई प्रकार के प्रस्तुतियों और एक से अधिक प्रस्तुतियां हैं जो विभिन्न एकाधिक विचारों के साथ काम कर रही हैं।

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

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

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

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

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

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

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

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


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

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


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

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

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

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

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

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

वेब पर यह सबसे अच्छा स्पष्टीकरण है जो मुझे मिल सकता है।


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




एमवीपी

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

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

ईवेंट बाध्यकारी प्रस्तुतकर्ता में एक व्यू इंटरफ़ेस से लागू किया जाएगा।

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

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

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

MVC

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

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

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

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


एमवीपी: दृश्य प्रभारी है।

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

एमवीसी: नियंत्रक प्रभारी है।

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


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

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


बहुत से लोगों को पता नहीं है कि क्रमशः एमवीसी और एमवीपी में नियंत्रक और प्रेजेंटर के बीच क्या अंतर है।

यह एक साधारण समीकरण कहाँ है

एमवीसी व्यू = एमवीपी का देखें और प्रस्तुतकर्ता

एमवीपी मॉडल = एमवीसी के नियंत्रक और मॉडल

अधिक जानकारी इस http://includeblogh.blogspot.com.eg/2016/07/the-difference-and-relationship-between.html संदर्भ लें


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

यदि हम डेटा संरचनाओं + एल्गोरिदम के रूप में प्रोग्रामिंग देखते हैं, तो डेटा संरचनाओं को जितना संभव हो सके स्पष्ट करना सबसे अच्छा नहीं होगा, और फिर एल्गोरिदम विकसित करें जो प्रत्येक जितना संभव हो उतना डेटा के टुकड़े के रूप में निर्भर करता है, जिसमें एल्गोरिदम के बीच न्यूनतम युग्मन होता है ?

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

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

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


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

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

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

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

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

( प्रस्तुतकर्ता को कॉल करना देखें | नियंत्रक ...) [ एमवीपी | एमवीसी ]

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

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

देखें : हाँ, ... यहाँ यह है ... "पियानो" [ एमवीपी | एमवीसी ]

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

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

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

आदर्श : अरे प्रेजेंटर | नियंत्रक , मुझे जांचने दो ... [ एमवीपी | एमवीसी ]

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

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

-------------- यह वह जगह है जहां एमवीपी और एमवीसी अलग हो जाते हैं ---------------

आदर्श : मुझे आपके लिए एक सूची मिली, प्रेजेंटर , यहां यह JSON "[{" नाम ":" पियानो शिक्षक "," वर्ष ": 2001}, {" नाम ":" पियानो "," वर्ष ": 1 99 3} ] "[ एमवीपी ]

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

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

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

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

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

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

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


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

  1. मॉडल - समायोजन मॉडल (POJO, JavaBeans, आदि), विभिन्न स्रोतों से डेटा (डेटाबेस, सर्वर परिणाम, कैश, एंड्रॉइड फ़ाइल सिस्टम, आदि)।

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

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


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

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

उनमें से दोनों टीडीडी सक्षम करते हैं और डाउनसाइड्स और अपसाइड होते हैं।

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

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

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


यह भी याद रखने योग्य है कि विभिन्न प्रकार के एमवीपी भी हैं। फाउलर ने पैटर्न को दो में निष्क्रिय कर दिया है - निष्क्रिय दृश्य और पर्यवेक्षण नियंत्रक।

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

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

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

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

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

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

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

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


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

MVC

एमवीपी


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

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

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

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

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



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

एमवीसी बनाम एमवीपी के बीच मतभेदों के बारे में here एक चर्चा here

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

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

ऐसा कहा जाता है कि, एएसपी.नेट एमवीसी इन परिभाषाओं से एक एमवीपी ढांचा है क्योंकि नियंत्रक दृश्य को पॉप्युलेट करने के लिए मॉडल तक पहुंचता है जिसका मतलब कोई तर्क नहीं है (केवल नियंत्रक द्वारा प्रदान किए गए चर प्रदर्शित करता है)।

शायद एमवीपी से एएसपी.नेट एमवीसी भेद का विचार प्राप्त करने के लिए, स्कॉट हंसेलमैन द्वारा इस मिक्स प्रस्तुति को देखें।


एमवीसी (मॉडल व्यू कंट्रोलर)

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

एमवीपी (मॉडल व्यू प्रेजेंटर)

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

अधिक Reference



एमवीसी, एमवीपी, एमवीवीएम

एमवीसी (पुराना एक)

एमवीपी (इसके कम युग्मन के कारण अधिक मॉड्यूलर। प्रस्तुतकर्ता दृश्य और मॉडल के बीच मध्यस्थ है)

एमवीवीएम (आपके पास पहले से ही वीएम और यूआई घटक के बीच दो-तरफा बाध्यकारी है, इसलिए यह एमवीपी से अधिक स्वचालित है)

एक और छवि:





design-patterns model-view-controller user-interface mvp glossary