🌮 🙅 🎟️ शुरुआती पैटर्न: एमवीसी बनाम एमवीपी बनाम एमवीवीएम 🎺 💰 🕴🏿

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

संदर्भ

पहली चीज जो मैं शुरू करना चाहूंगा, वह है बाहरी सामग्रियों के लिंक, जिन्होंने मुझे इस लेख को लिखने की प्रक्रिया में निर्देशित किया:

परिचय

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

पैटर्न

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

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

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

आदर्श

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

मॉडल में निम्नलिखित विशेषताएं हैं:

एक मॉडल एक आवेदन का व्यावसायिक तर्क है;
मॉडल को अपने बारे में ज्ञान है और वह नियंत्रकों और अभ्यावेदन के बारे में नहीं जानता है;
कुछ परियोजनाओं के लिए, एक मॉडल सिर्फ एक डेटा परत (DAO, डेटाबेस, XML फ़ाइल) है;
अन्य परियोजनाओं के लिए, एक मॉडल एक डेटाबेस प्रबंधक, वस्तुओं का एक समूह, या सिर्फ आवेदन तर्क है;

प्रतिनिधित्व (देखें)

प्रस्तुति के कर्तव्यों में मॉडल से प्राप्त डेटा प्रदर्शित करना शामिल है। हालाँकि, प्रदर्शन सीधे मॉडल को प्रभावित नहीं कर सकता है। हम कह सकते हैं कि एक दृश्य में डेटा तक केवल पढ़ने की पहुंच है।

दृश्य में निम्नलिखित विशेषताएं हैं:

दृश्य किसी भी तरह से मॉडल से प्राप्त डेटा के प्रदर्शन को लागू करता है;
कुछ मामलों में, दृश्य में कुछ व्यावसायिक तर्क को लागू करने वाले कोड हो सकते हैं।

प्रस्तुति के उदाहरण: एचटीएमएल पेज, डब्ल्यूपीएफ फॉर्म, विंडोज फॉर्म।

अंतर एमवीसी और एमवीवीएम और एमवीपी

MVC पैटर्न के सबसे आम प्रकार हैं:

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

उनमें से प्रत्येक पर विचार करें और तुलना करें।

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

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

प्रस्तुतकर्ता के संकेत:

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

कार्यान्वयन:
प्रत्येक दृश्य को एक उपयुक्त इंटरफ़ेस लागू करना होगा। प्रस्तुति इंटरफ़ेस उपयोगकर्ता के साथ बातचीत करने के लिए आवश्यक कार्यों और घटनाओं के एक सेट को परिभाषित करता है (उदाहरण के लिए, IView .ShowErrorMessage (string msg))। प्रस्तुतकर्ता के पास संबंधित इंटरफ़ेस के कार्यान्वयन के लिए एक लिंक होना चाहिए, जो आमतौर पर कंस्ट्रक्टर में पारित किया जाता है।
प्रस्तुति तर्क में प्रस्तुतकर्ता के उदाहरण के लिए एक लिंक होना चाहिए। सभी प्रस्तुति की घटनाओं को प्रस्तुतकर्ता के लिए प्रसंस्करण के लिए प्रेषित किया जाता है और प्रस्तुति तर्क द्वारा लगभग कभी संसाधित नहीं किया जाता है (अन्य विचारों के निर्माण सहित)।

उपयोग का उदाहरण: विंडोज फॉर्म।

मॉडल-व्यू-व्यू मॉडल

यह दृष्टिकोण आपको प्रस्तुति तत्वों को व्यू मॉडल के गुणों और घटनाओं के साथ जोड़ने की अनुमति देता है। यह तर्क दिया जा सकता है कि इस पैटर्न की प्रत्येक परत किसी अन्य परत के अस्तित्व के बारे में नहीं जानती है।

दृश्य मॉडल के संकेत:

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

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

केस स्टडी: डब्ल्यूपीएफ

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

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

नियंत्रक संकेत

नियंत्रक निर्धारित करता है कि किस दृश्य को इस समय प्रदर्शित किया जाना चाहिए;
दृश्य घटनाएं केवल नियंत्रक को प्रभावित कर सकती हैं। नियंत्रक मॉडल को प्रभावित कर सकता है और एक अलग दृश्य को परिभाषित कर सकता है।
केवल एक नियंत्रक के लिए कई विचार संभव हैं;

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

केस स्टडी: MVC ASP.NET

सारांश

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

सामान्य पैटर्न चयन नियम

MVVM

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

एमवीपी

इसका उपयोग उस स्थिति में किया जाता है जब डेटा बाइंडिंग असंभव हो (बाइंडिंग का उपयोग नहीं किया जा सकता);
एक सामान्य उदाहरण विंडोज फॉर्म का उपयोग हो सकता है।

MVC

इसका उपयोग उस स्थिति में किया जाता है जहां प्रस्तुति और अनुप्रयोग के अन्य भागों के बीच संचार असंभव है (और आप एमवीवीएम या एमवीपी का उपयोग नहीं कर सकते हैं);
एक लगातार उपयोग का मामला ASP.NET MVC है।

निष्कर्ष

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

आपके समय के लिए बहुत बहुत धन्यवाद, पढ़ने का आनंद लें!

शुरुआती पैटर्न: एमवीसी बनाम एमवीपी बनाम एमवीवीएम