MVC + परिदृश्य बनाम मोटा नियंत्रक

आधुनिक PHP फ्रेमवर्क (सिम्फनी, लारवेल, इसके बाद हर जगह) पूरी तरह से दिखाते हैं कि मॉडल-व्यू-कंट्रोलर पैटर्न को लागू करना इतना सरल नहीं है। किसी कारण के लिए सभी कार्यान्वयन फैट कंट्रोलर्स ( fat controllers ) के लिए प्रवण होते हैं, सभी की निंदा करते हैं, और डेवलपर्स, और खुद को रूपरेखा।

ऐसा क्यों है? और क्या इसे संभालने का कोई तरीका है? चलो ठीक है।

शब्दावली

मॉडल - मॉडल (अनुरोधित डेटा का शेपर)
देखें - दृश्य (मॉडल डेटा डेकोरेटर)
नियंत्रक - नियंत्रक (अनुरोध के अनुसार मॉडल-व्यू समन्वयक)
खाका - प्रस्तुति का खाका
प्रतिपादन - प्रतिपादन (गठन, प्रस्तुति छवि का डिजाइन)
रेंडरर - रेंडरर (शेपर, प्रस्तुति छवि के डिजाइनर)

मोटा नियंत्रक

यहाँ एक विशिष्ट वसा नियंत्रक है:

 class UserController { /** *   *      ID */ public function actionUserHello($userId) { //         ( ) $user = UserModel::find($userId); //       -   $name = $user->firstName.' '.$user->lastName; //         $view = new View('hello', ['name' => $name]); //  ( )     return $view->render(); } }

हम क्या देखते हैं? हम देखते हैं vinaigrette! नियंत्रक में जो कुछ भी संभव है वह मिश्रित है - दोनों मॉडल, और प्रस्तुति, और, वास्तव में, नियंत्रक खुद!

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

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

संक्षिप्त सारांश:

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

इन कमियों को दूर करने के लिए, MVC के घटकों पर करीब से नज़र डालना अच्छा होगा।

दृश्य एक रेंडरर है

पहले दोष पर एक नज़र डालें:

एमवीसी-व्यू (देखें) की संकीर्ण व्याख्या केवल "किसी पीएचपी के साथ देखें " के बजाय "PHP फ़ाइल में टेम्पलेट के साथ देखें" ।

यहां, सब कुछ काफी सरल है - समस्या का समाधान पहले से ही समस्या के बहुत सूत्रीकरण में इंगित किया गया है। हमें केवल यह कहना है कि कोई भी रेंडर देखने का उपयोग कर सकता है। इसे लागू करने के लिए, नई renderer संपत्ति को व्यू क्लास में जोड़ें:

 class View { public $template, $data, $renderer; public function __costruct($template, $data, $renderer = NULL) {} }

इसलिए, हमने दृश्य के लिए एक नई renderer संपत्ति को परिभाषित किया है। सबसे सामान्य मामले में, इस संपत्ति का मूल्य कोई भी callable कार्य हो सकता है जो प्रेषित टेम्पलेट का उपयोग करके इसे हस्तांतरित डेटा की एक छवि बनाता है।

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

क्या यह सरल है? बस। वास्तव में इतना आसान नहीं है। तथ्य यह है कि जो View एमवीसी में है वह वास्तव में वह View नहीं है जो रूपरेखा में है। View जो View है वह टेम्पलेट के बिना नहीं रह सकता। लेकिन View , जो एमवीसी में, किसी कारण से इन समान टेम्पलेट्स के बारे में कुछ भी नहीं जानता है। क्यों? हां, क्योंकि एमवीसी View , यह एक छवि में मॉडल डेटा का कोई भी कनवर्टर है , और न केवल एक टेम्पलेट इंजन है। जब हम अनुरोध हैंडलर में ऐसा कुछ लिखते हैं:

 $name = ' '; return "Hello, {$name}!";

या यहां तक कि:

 $return json_encode($name); // Ajax response

तब हम वास्तव में उस View को परिभाषित करते हैं जो MVC में है, बिना किसी View को View जो चौखटे में है!

लेकिन अब सब कुछ वास्तव में सरल है: वे View , जो चौखटे में - यह उन View का सबसेट है, जो एमवीसी में हैं। इसके अलावा, एक बहुत ही संकीर्ण सबसेट, अर्थात्, यह केवल PHP फाइलों पर आधारित एक टेम्पलेट इंजन है।

सारांश: यह , अर्थात डेटा छवि का कोई भी सज्जाकार वह View है जो MVC में है। और वे View , जो चौखटे में हैं, एक प्रकार का ।

डोमेन मॉडल / मॉडल देखें (ViewModel / DomainModel)

अब दूसरी कमियां देखें:

एमवीसी-मॉडल की संकीर्ण व्याख्या केवल "डेटाबेस मॉडल डोमेन" के बजाय "प्रस्तुति के लिए कोई डेटा संकलक । "

यह सभी के लिए स्पष्ट है कि एमवीसी मॉडल एक जटिल चीज है जिसमें अन्य टुकड़े होते हैं। एक मॉडल (DomainModel) और एक प्रस्तुति मॉडल (ViewModel): समुदाय दो घटकों में मॉडल को विघटित करने के लिए सहमत है।

एक डोमेन मॉडल वह है जो डेटाबेस में संग्रहीत होता है, अर्थात। सामान्यीकृत मॉडल डेटा। विभिन्न क्षेत्रों में 'प्रथम नाम' और 'अंतिम नाम' टाइप करें। मॉडल के इस विशेष भाग के साथ चौखटे पर कब्जा कर लिया जाता है, क्योंकि डेटा भंडारण का अपना ब्रह्मांड है, जिसका अच्छी तरह से अध्ययन किया गया है।

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

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

परिदृश्य बनाम वसा नियंत्रक

चौखटे का एक अंतिम दोष है:

वे तथाकथित "थिक कंट्रोलर्स" के उपयोग को उकसाते हैं जिसमें एक ही समय में सभी तर्क होते हैं: व्यापार, प्रस्तुति और बातचीत। यह पूरी तरह से MVC के मुख्य लक्ष्य को नष्ट कर देता है - त्रय के घटकों के बीच जिम्मेदारियों का विभाजन।

यहां हम एमवीसी की मूल बातें पर पहुंचते हैं। चलो स्पष्ट हो। इसलिए, MVC ने त्रय के घटकों के बीच जिम्मेदारियों के निम्नलिखित वितरण को माना:

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

आगे बढ़ो। जिम्मेदारियों के दो स्तर स्पष्ट रूप से दिखाई देते हैं:

संगठनात्मक स्तर नियंत्रक है,
कार्यकारी स्तर मॉडल और प्रतिनिधित्व है।

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

नियंत्रक इस तरह से चलता है:

एक आवेदन से एक अनुरोध प्राप्त करता है,
इस अनुरोध के लिए कौन सा मॉडल और कौन सा दृश्य उपयोग करना है, यह तय करता है,
चयनित मॉडल को कॉल करता है और इससे डेटा प्राप्त करता है,
मॉडल से प्राप्त डेटा के साथ चयनित दृश्य को आमंत्रित करता है,
एप्लिकेशन द्वारा वापस देखे गए डेटा को लौटाता है।

कुछ इस तरह। इस योजना में आवश्यक बात यह है कि मॉडल और प्रतिनिधित्व क्वेरी निष्पादन की श्रृंखला में लिंक हो। इसके अलावा, क्रमिक लिंक द्वारा: सबसे पहले, मॉडल अनुरोध को कुछ डेटा में परिवर्तित करता है, फिर ये मॉडल डेटा व्यू द्वारा एक विशिष्ट अनुरोध के लिए आवश्यकतानुसार उत्तर में बदल दिए जाते हैं। जैसे, एक humanoid अनुरोध को templatizators के साथ नेत्रहीन सजाया गया है, एक Android अनुरोध JSON एन्कोडर के साथ सजाया गया है।

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

>>

वहाँ अच्छी तरह से एक श्रृंखला हो सकती है

>> >>

सवाल अपने आप से भीख माँगता है: केवल दो या तीन ही क्यों? और अगर आपको और अधिक की आवश्यकता है? स्वाभाविक उत्तर है, ईश्वर के लिए, जितनी आवश्यकता है, उतने ही ले लो!

अन्य उपयोगी कलाकार तुरंत दिखाई देते हैं: सत्यापनकर्ता, पुनर्निर्देशक, विभिन्न रेंडरर्स, और सामान्य रूप से सब कुछ जो अप्रत्याशित है, लेकिन मनभावन है।

चलो फिर से तैयार करते हैं:

कार्यकारी स्तर MVC ( - ) लिंक की एक श्रृंखला के रूप में लागू किया जा सकता है, जहां प्रत्येक लिंक पिछले लिंक के आउटपुट को अगले इनपुट के लिए कनवर्ट करता है।
पहले लिंक का इनपुट आवेदन अनुरोध है।
अंतिम लिंक का आउटपुट अनुरोध के लिए आवेदन प्रतिक्रिया है।

मैंने इस श्रृंखला को Scenario कहा है, लेकिन श्रृंखला के लिंक के लिए मैंने अभी तक नाम तय नहीं किया है। वर्तमान विकल्प एक दृश्य (एक स्क्रिप्ट के हिस्से के रूप में), एक फिल्टर (एक डेटा कनवर्टर के रूप में), एक स्क्रिप्ट कार्रवाई है। सामान्यतया, लिंक के लिए नाम इतना महत्वपूर्ण नहीं है, एक और महत्वपूर्ण बात है।

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

परिदृश्य का उपयोग करने से MVC पैटर्न की एक और भिन्नता हो जाती है, मैंने इस भिन्नता को MVCS - Model-View-Controller-Scenario ।

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

MVCS उदाहरण

अब देखते हैं कि इस लेख की शुरुआत में फैट कोर्टोलर का उदाहरण MVCS में कैसे लागू किया जा सकता है।

हम MVCS नियंत्रक बनाकर शुरू करते हैं:

 $mvcs = new MvcsController();

MVCS नियंत्रक को बाहरी राउटर से एक अनुरोध प्राप्त होता है। राउटर को फॉर्म के यूआरआई को 'यूजर / हेलो / एक्सएक्सएक्स' में इस तरह की कार्रवाई और अनुरोध पैरामीटर में परिवर्तित करें:

 $requestAction = 'user/hello'; //   $requestParams = ['XXX']; //   -

यह देखते हुए कि MVCS नियंत्रक URI के बजाय स्क्रिप्ट स्वीकार करता है, हमें अनुरोध की कार्रवाई के लिए कुछ स्क्रिप्ट को मैप करने की आवश्यकता है। यह MVCS कंटेनर में सबसे अच्छा किया जाता है:

 //   MVCS  URI  $mvcs->set('scenarios', [ 'user/hello' => 'UserModel > UserViewModel > view, hello', ..., ]);

आइए इस परिदृश्य पर करीब से नज़र डालें। यह एक '>' द्वारा अलग किए गए तीन डेटा कन्वर्टर्स की एक श्रृंखला है:

'UserModel' डोमेन मॉडल 'उपयोगकर्ता' का नाम है, मॉडल का इनपुट अनुरोध पैरामीटर होगा, आउटपुट मॉडल का वास्तविक डेटा होगा:
'UserViewModel' दृश्य मॉडल का नाम है जो डोमेन डेटा को दृश्य डेटा में परिवर्तित करता है,
is व्यू, हैलो ’एक PHP टेम्पलेट के लिए सिस्टम व्यू, टेम्पलेट’ है जिसे 'हैलो ’कहा जाता है।

अब हमें केवल MVCS कंटेनर में एक क्लोजर फंक्शन के रूप में स्क्रिप्ट में शामिल दो ट्रांसफार्मर जोड़ने की आवश्यकता है:

 //   UserModel $mvcs->set('UserModel', function($id) { $users = [ 1 => ['first' => '', 'last' => ''], 2 => ['first' => '', 'last' => ''], ]; return isset($users[$id]) ? $users[$id] : NULL; }); //   UserViewModel $mvcs->set('UserViewModel', function($user) { //    PHP  : 'echo "Hello, $name!"'; return ['name' => $user['first'].' '.$user['last']]; });

और वह सब है! प्रत्येक अनुरोध के लिए, संबंधित स्क्रिप्ट और उसके सभी दृश्यों (सिस्टम वाले को छोड़कर, जैसे 'दृश्य') को निर्धारित करना आवश्यक है। और कुछ नहीं।

और अब हम विभिन्न अनुरोधों के लिए MVCS का परीक्षण करने के लिए तैयार हैं:

 //        $scenarios = $mvcs->get('scenarios'); $scenario = $scenarios[$requestAction]; //      ... //   'user/hello/1'  ' '   'hello' $requestParams = ['1']; $response = $mvcs->play($scenario, $requestParams); //   'user/hello/2'  ' '   'hello' $requestParams = ['2']; $response = $mvcs->play($scenario, $requestParams);

PHP MVCS कार्यान्वयन को github.com पर होस्ट किया गया है।
यह उदाहरण MVCS निर्देशिका में है।

MVC + परिदृश्य बनाम वसा नियंत्रक