वेब के लिए एमवीसी: कहीं भी आसान नहीं है

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

विकिपीडिया लेख (जो है, ऐसा लगता है कि ज्यादातर लोग जो एमवीसी सीखना शुरू कर रहे हैं, वहां सबसे अधिक संभावना है) अशुद्धि और अस्पष्ट शब्द के साथ पूरा होता है, परिभाषा ही, वास्तव में, गलत है, और उपरोक्त योजना बस वेब पर उपयोग किए गए एक के अनुरूप नहीं है। सामान्य रूप से और जब PHP में विकसित कर रहे हैं - विशेष रूप से।

MVC पैटर्न की सबसे सही परिभाषा मुझे यहाँ मिली:

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

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

आइए क्लासिक वेब एप्लिकेशन स्कीमा देखें:

चित्र 1

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

अनुरोध 1 प्राप्त होने के बाद, नियंत्रक इसका विश्लेषण करता है, और प्रसंस्करण के परिणामों के आधार पर यह निम्नलिखित उत्तर विकल्प दे सकता है (उत्तर संख्या 4 क्यों है, यह निम्न आंकड़ों से स्पष्ट हो जाएगा):

1. तुरंत एक त्रुटि प्रतिक्रिया दें (उदाहरण के लिए, जब कोई पृष्ठ मौजूद नहीं है, तो अनुरोध करें कि केवल HTTP हेडर "404 नहीं") दें

2. यदि प्राप्त अनुरोध 1 को सही माना जाता है, तो, यह निर्भर करता है कि यह डेटा देखने या संशोधित करने का अनुरोध है, नियंत्रक उपयुक्त मॉडल विधि, जैसे कि सहेजें या लोड (छवि 2 में अनुरोध 2) को कॉल करता है।

चित्र 2

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

<? mixed Product_Load (int $id) { ... } //         FALSE   bool Product_Save (array $data) { ... } //  TRUE     $data,  FALSE   ?> 

इसलिए, मॉडल से प्राप्त रिस्पांस 2 के आधार पर, नियंत्रक निर्णय लेता है कि प्रारंभिक अनुरोध 1 को अंतिम प्रतिक्रिया बनाने के लिए किस दृश्य को कॉल किया जाए:

3.1। विफलता के मामले में - त्रुटि संदेश के लिए देखें
3.2। सफलता के मामले में - अनुरोधित डेटा या संदेशों को उनके सफल भंडारण के बारे में प्रदर्शित करने के लिए प्रस्तुत करना (यदि अनुरोध 1 डेटा को बदलना था)।

चित्र 3

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

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

पिछला पैराग्राफ काफी स्पष्ट नहीं है? इसे भूल जाओ, क्योंकि प्रत्येक दृश्य केवल एक अलग PHP फ़ाइल है, और PHP को ही डिज़ाइन किया गया है ताकि यदि हम अनुरोध 3 को निष्पादित करने के लिए शामिल कथन, उत्तर 3 और उत्तर 4 का उपयोग करें (याद रखें, यह अनुरोध 1 का उत्तर है? ) PHP के माध्यम से स्वचालित रूप से ब्राउज़र को दिया जाता है।

आइए एक उदाहरण देखें।

हमारे पास दो प्रेजेंटेशन विकल्प (टेम्प्लेट) हैं जिनमें

<! - HTML.header -> का अर्थ होगा HTML कोड जो उत्पन्न वेब दस्तावेज़ में मुख्य सामग्री से पहले है (अर्थात इसमें doctype टैग, हेड कंटेनर, पेज हेडर कोड, आदि), और <शामिल हैं! - HTML.footer -> - उसी के बारे में, केवल पृष्ठ के पाद लेख के लिए।

लिस्टिंग 1. Product.tpl.php टेम्पलेट उत्पाद के बारे में जानकारी प्रदर्शित करता है (जो कि इसके कॉल के समय पहले से ही $ उत्पाद वस्तु शामिल है):

 <!-- HTML.header --> <h1><?=$product->Title;?></h1> <p>:<b class="price"><?=$product->Price;?></b></p> <p class="description"><?=$product->Description;?></p> <!-- HTML.footer --> 

लिस्टिंग 2. त्रुटि .pl.php टेम्पलेट एक त्रुटि संदेश प्रदर्शित करता है (जो $ त्रुटि चर में निहित है):

 <!-- HTML.header --> <h1 class="error">: <?=$error;?></h1> <!-- HTML.footer --> 

लिस्टिंग 3. उत्पाद प्रदर्शित करने के लिए इस्तेमाल किया जाने वाला product.php नियंत्रक कुछ इस तरह दिखाई देगा:

 <? include 'product.class.php'; //        //     , ,  //         function Error ($error) { //        ,  : header('  , , 400  404'); $error = '   , ,   '; include 'error.tpl.php'; //     exit; } if (!$id = ...) //  ""   1 error(...); //    if (!$user->Access(...)) error(403); if (!$product = Product::Load($id)) //  2    2 error('     '); include 'product.tpl.php'; //  3   3  4 ?> 

जो लोग सुंदर और अनुकूलित कोड पसंद करते हैं, वे देख सकते हैं कि HTML.header और HTML.footer ब्लॉकों को दोनों टेम्प्लेट (वे व्यूज) error.tpl.php और product.tpl.php में डुप्लिकेट किया गया है, और वे शायद उन्हें उत्पाद नियंत्रक में डालना चाहते हैं । save.php :

 <!-- HTML.header --> <? //      3 ?> <!-- HTML.footer --> 

.... और इस प्रकार मूल MVC नियम का उल्लंघन करते हैं - नियंत्रक, मॉडल और दृश्य को अलग करें।

हालाँकि, डुप्लिकेट कोड एक स्पष्ट बुराई है। क्या करें?
हमें MVC से HMVC में जाना होगा!
लेकिन यह एक अलग लेख का विषय है।