एमवी पैटर्न के लिए वेब एप्लिकेशन डिजाइन धोखा शीट

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

MVC

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


इंटरनेट पर "एमवीसी" के अनुरोध पर आप कई अलग-अलग योजनाएं पा सकते हैं जिसमें भ्रमित होना बहुत आसान है। आइए इसकी जगह पर सब कुछ डालने की कोशिश करें। योजना 1 पर विचार करें:


1. जब कोई उपयोगकर्ता किसी वेब संसाधन में प्रवेश करता है, तो इनिशियलाइज़ेशन स्क्रिप्ट एप्लिकेशन का एक उदाहरण बनाता है और इसे निष्पादन के लिए लॉन्च करता है।
2. सामने नियंत्रक की सूचकांक कार्रवाई निष्पादित की जाती है, जो मुख्य पृष्ठ का एक दृश्य उत्पन्न करता है।
3. दृश्य उपयोगकर्ता को प्रदर्शित किया जाता है।

एक मॉडल का उपयोग किए बिना पहले तीन चरण एक सरल श्रृंखला है। अगला वह क्रम है जहां मॉडल शामिल है:

4. एप्लिकेशन को उपयोगकर्ता से अनुरोध प्राप्त होने के बाद, अनुरोधित नियंत्रक का एक उदाहरण बनाया जाता है और निर्दिष्ट कार्रवाई को कहा जाता है।
5. इस क्रिया में, इसे बदलने वाले मॉडल के तरीकों को कहा जाता है।
6. एक दृश्य उत्पन्न होता है (या दृश्य को एक मॉडल अपडेट के बारे में सूचित किया जाता है)।
7. दृश्य प्रदर्शन के लिए डेटा का अनुरोध करता है।
8. मॉडल अनुरोधित डेटा लौटाता है।
9. दृश्य उपयोगकर्ता को परिणाम प्रदर्शित करता है।


ऐसी योजना भी है - योजना 2:


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


कुछ आरेखों पर, आप तीर को दृश्य से नियंत्रक तक देख सकते हैं। इस मामले पर विचार करें - योजना 3:

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

चरण 4, वास्तव में, एक अन्य चरण 1 के बराबर है, एक नए चक्र को प्रारंभ करता है ... इसलिए, सभी योजनाओं में, आप नियंत्रक से देखने के लिए दिशा में एक अंतर्निहित कनेक्शन मान सकते हैं।

एमवीपी

अब MVP (मॉडल-व्यू-प्रस्तोता) पैटर्न आरेख देखें - आरेख 4:

1. आवेदन के बाद उपयोगकर्ता से अनुरोध प्राप्त होता है, अनुरोधित प्रस्तुतकर्ता और कार्रवाई निर्धारित की जाती है। एप्लिकेशन इस प्रस्तोता का एक उदाहरण बनाता है और एक्शन विधि लॉन्च करता है।
2. एक क्रिया पद्धति में मॉडल कॉल हो सकती है, उदाहरण के लिए, डेटाबेस से जानकारी पढ़ना।
   
3. मॉडल डेटा लौटाता है।
4. उसके बाद, क्रिया एक दृश्य बनाती है जिसमें मॉडल से प्राप्त डेटा प्रसारित होता है।
5. उत्पन्न दृश्य उपयोगकर्ता को प्रदर्शित किया जाता है।

एमवीपी के अलावा, अन्य एमवीसी-व्युत्पन्न पैटर्न हैं, जैसे कि एमवीवीएम और एचएमवीसी ।

HMVC

HMVC के कार्यान्वयन (पदानुक्रमित मॉडल व्यू कंट्रोलर) पैटर्न कोहाना वेब फ्रेमवर्क में उपयोग किया जाता है। MVC से महत्वपूर्ण अंतर पर विचार करें - योजना 5:


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

MVVM

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

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

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

एमवीसी में, तर्क को मॉडल में वायर्ड किया जाता है, इसे नियंत्रक में भी रखा जा सकता है, लेकिन इसकी सही आलोचना की जाती है (स्टूपिड फैट कंट्रोलर)। इसके विपरीत, MVVM में, तर्क ViewModel की "मध्यवर्ती" परत में रखा गया है। MVVM योजना पर विचार करें - योजना 6:

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

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

निष्कर्ष

इस प्रश्न का उत्तर देने की कोशिश करने की आवश्यकता नहीं है कि इनमें से कौन सा पैटर्न बेहतर है, आदि ... आपको केवल मुख्य विचार बनाने की ज़रूरत है - "विभाजित और जीत", क्योंकि यह बहुत महत्वपूर्ण है कि परतें जितनी स्वतंत्र और आसानी से प्रतिस्थापित हो सकें।