एमवीसी पर एमवीपी के सुधार क्या हैं?

मैंने मॉडल-व्यू-कंट्रोलर (MVC) और मॉडल-व्यू-प्रस्तुतकर्ता (MVP) पैटर्न के बारे में तीन दिनों तक पढ़ा है । और एक सवाल है जो मुझे बहुत परेशान करता है। सॉफ्टवेयर डिजाइनर ने एमवीपी का आविष्कार क्यों किया, जब पहले से ही एक एमवीसी था?

उन्हें किन समस्याओं का सामना करना पड़ा, जो MVC ने हल नहीं किया (या बुरी तरह से हल किया गया), लेकिन MVP हल कर सकता है? एमवीपी को हल करने के लिए कौन सी समस्याएं हैं?

मैंने एमवीपी के इतिहास और स्पष्टीकरण के बारे में या एमवीसी और एमवीपी के बीच मतभेदों के बारे में बहुत सारे लेख पढ़े हैं, लेकिन मेरे सवालों का कोई स्पष्ट जवाब नहीं था।

मेरे द्वारा पढ़े गए लेखों में से एक में यह कहा गया था:

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

इसलिए, मैं समझ नहीं पा रहा हूं, लेकिन क्या यह वास्तव में दूसरे तरीके से हो सकता है, जैसे कि जीयूआई घटक उपयोगकर्ता इनपुट को खुद से नहीं संभालते हैं? और वास्तव में "अपने आप से संभाल" का क्या मतलब है?

— विजेता
स्रोत

का डुप्लीकेट stackoverflow.com/questions/2056/...

— qwerty_so

मुझे लगता है कि यह "द एम्परर्स न्यू क्लोथ्स" है, जो मिकीसॉफ्ट का एक नया शब्द है।

— qwerty_so

विक्टर, क्या आपके पास "क्यों दो अलग-अलग पैटर्न हैं" के अलावा एक विशिष्ट प्रश्न है? दो अलग-अलग पैटर्न हैं क्योंकि वे एक ही समस्या को दो अलग-अलग तरीकों से हल करते हैं। यदि यह मदद करता है, तो मॉडल और दृश्य अनिवार्य रूप से दोनों पैटर्न में समान हैं। एक नियंत्रक और एक प्रस्तुतकर्ता के बीच अंतर पर ध्यान दें। आप यहाँ और अधिक मदद पा सकते हैं: लिंक्डइन

— रॉबर्ट हार्वे

"मैंने एमवीसी और एमवीपी पैटर्न के बारे में तीन दिनों तक पढ़ा है।" ओह। मेरा सुझाव है कि आप आराम से गर्म स्नान करें या बत्तख से भरे तालाब या कुछ और पत्थरों को छोड़ दें। किसी भी व्यावहारिक अनुप्रयोग की अनुपस्थिति में, ऐसा पढ़ने से वास्तव में आपका मस्तिष्क पिघल सकता है!

— user1172763

आप जिस तरह का उत्तर चाहते हैं, वह इन पैटर्नों का उपयोग करके कुछ बनाना है । तब तुम प्रबुद्ध हो जाओगे।

— रॉबर्ट हार्वे

जवाबों:

MVC वैचारिक रूप से सुरुचिपूर्ण है:

उपयोगकर्ता इनपुट नियंत्रक द्वारा नियंत्रित किया जाता है
नियंत्रक मॉडल को अपडेट करता है
मॉडल दृश्य / उपयोगकर्ता इंटरफ़ेस को अपडेट करता है

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

हालाँकि: MVC में डेटा- और घटना-प्रवाह परिपत्र है। और दृश्य में अक्सर महत्वपूर्ण तर्क शामिल होंगे (जैसे उपयोगकर्ता कार्यों के लिए इवेंट हैंडलर)। एक साथ, ये गुण प्रणाली को परीक्षण करने के लिए कठिन और बनाए रखने में कठिन बनाते हैं।

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

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

इसके निम्नलिखित फायदे हैं:

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

लेकिन इस दृष्टिकोण में कुछ कमियां भी हैं:

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

— आमोन
स्रोत

अच्छा जवाब है, लेकिन आधुनिक रूप से एमवीसी आमतौर पर इवेंट हैंडलर को छोड़कर (यदि कोई हो) का उपयोग स्थानीय रूप से सत्यापन के लिए नहीं करता है, और मैं उन घटनाओं को एमवीसी का हिस्सा उचित नहीं मानता। ऐसा इसलिए है कि हम क्यों एमवीपी और MVVM की है। एमवीसी अनिवार्य रूप से सर्वर-साइड है।

— रॉबर्ट हार्वे

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

— विक्टर

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

— आमोन

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

— आमोन

@RobertHarvey मैं तर्क दूंगा कि "एमवीसी" नामक वेब वास्तव में "एमवीसी" कभी भी मूल परिभाषा नहीं थी। जिसे भी अपहृत किया गया है, उसे भरी हुई अवधि चुनने और सभी को भ्रमित करने के लिए सिर पर उल्टा मारना चाहिए।

— jpmc26

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

— माइकल ब्राउन
स्रोत