MVC में M: क्यों मॉडल को गलत समझा जाता है और कम करके आंका जाता है (अनुवाद)

(यह लेख बहुत पुराना है, इसमें उठाए गए सवालों के अनुसार आज तक प्रासंगिक हैं और नियमित रूप से विभिन्न चर्चाओं में उठाए जाते हैं)

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

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

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

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

मॉडल समझ में नहीं आए

मॉडल को विभिन्न तरीकों से वर्णित किया जा सकता है। वास्तव में, केवल यह एक पूरी पुस्तक लिखी जा सकती है, बहुतों ने ऐसा ही किया है! आमतौर पर, दो मॉडल भूमिकाओं का वर्णन किया जाता है:

1. HTTP अनुरोधों के बीच स्थिति बनाए रखने के लिए मॉडल जिम्मेदार है

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

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

2. मॉडल में सभी नियमों और प्रतिबंधों को शामिल किया गया है, इस जानकारी के व्यवहार और उपयोग को नियंत्रित करता है।

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

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

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

प्रोग्रामिंग में, मोटे मॉडल शून्य-आकार वाले मॉडल के लिए बेहतर हैं।

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

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

द्वारा और बड़े, php डेवलपर्स काफी समझ में नहीं आता है कि एक मॉडल क्या है। कई लोग मॉडल को डेटाबेस तक पहुंच के लिए एक सुंदर शब्द मानते हैं, अन्य लोग इसे डेटाबेस तक पहुंचने के लिए अलग-अलग टेम्पलेट्स के बराबर करते हैं, जैसे कि एक्टिव रिकॉर्ड, डेटा मैपर और टेबल डेटा गेटवे। फ्रेमवर्क बहुत बार इस गिरावट को बढ़ावा देते हैं, अनायास ही, मुझे यकीन है, लेकिन ऊर्जावान है। पूरी तरह से समझ नहीं है कि एक मॉडल क्या है, यह इतना बड़ा विचार क्यों है, और इसे कैसे विकसित किया जाना चाहिए और तैनात किया जाना चाहिए, डेवलपर्स अनजाने में विकास के तरीकों के लिए एक अंधेरे मार्ग पर चलते हैं जिसे गरीब कहा जा सकता है।

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

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

मिसअंडरस्टूड, अंडरस्टिमेटेड, अनलव्ड: डिप्रेस्ड मॉडल्स

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

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

PHP में मॉडल हारे हुए हैं। स्मार्टी और उसके रिश्तेदारों के आगमन के बाद से, हर कोई प्रदर्शन के बारे में भावुक है। नियंत्रक भी बहुत महत्वपूर्ण हैं, क्योंकि वे डेटाबेस से डेटा पढ़ते हैं और उन्हें टेम्पलेट्स में पास करते हैं (आमतौर पर वीसी की व्याख्या)। हां, नियंत्रक मस्तिष्क में घिरे पृष्ठ नियंत्रक का एक तार्किक विकास है, जिसका उपयोग हर PHP डेवलपर और उसके कुत्ते ने PHP3 द्वारा किया है। कम से कम यह सबसे स्पष्ट लगता है। हम बाद में "नियंत्रक = पृष्ठ नियंत्रक" के मिथक को नष्ट कर देंगे।

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

लेकिन रुको ... आखिरकार, डेवलपर्स अभी भी काम कर रहे आवेदन लिखते हैं! और यदि वे एप्लिकेशन लॉजिक वाले मॉडल का उपयोग नहीं करते हैं, तो वे किस नरक का उपयोग कर रहे हैं!

फैट, गूंगा, बदसूरत नियंत्रक: शांति बनाते हैं (फैट स्टुपिड अग्ली कंट्रोलर्स: SUC इट अप)

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

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

कुछ भी असामान्य नहीं देखा? TTUK डेटा पर सभी संभव कार्य करता है। क्यों? क्योंकि एक मॉडल की अनुपस्थिति में, सभी एप्लिकेशन लॉजिक कंट्रोलर में चले जाते हैं, जो इसे एक प्रकार का उत्परिवर्ती मॉडल बनाता है! मैंने केवल "उत्परिवर्ती" शब्द का उपयोग नहीं किया। TTUK बहुत बड़े, भारी, बदसूरत और निश्चित रूप से मोटे होते हैं। एक छद्म प्रोग्रामर शब्द है जो बहुत सटीक वर्णन करता है कि क्या हो रहा है - " फूला हुआ ।" वे ऐसे कार्यों को अंजाम देते हैं, जिनके लिए उनका कभी इरादा नहीं था। यह ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के सभी सिद्धांतों के बिल्कुल विपरीत है। और वे व्यर्थ हैं! कुछ रहस्यमय कारणों से, डेवलपर्स मॉडल के बजाय TTUKi का उपयोग करना पसंद करते हैं, इस तथ्य के बावजूद कि ऐसे नियंत्रक वास्तव में सिर्फ उत्परिवर्ती मॉडल हैं।

हमारे मानसिक व्यायाम को याद रखें? यदि आप नियंत्रकों में सब कुछ डालते हैं, तो एप्लिकेशन को दूसरे ढांचे में पोर्ट करना एक अत्यंत कठिन कार्य बन जाएगा। ऐसे तंग बंधन, केंट बेक के प्रशंसक इसे "कोड गंध" कहते हैं। और यह TTUKs में गंध का एकमात्र स्रोत नहीं है। TTUK बड़े पैमाने पर तरीकों के साथ बड़े होते हैं, कई भूमिकाएं (आमतौर पर प्रत्येक विधि के लिए एक), कई कोड दोहराते हैं जिन्हें कार्यक्षमता द्वारा बाहरी कक्षाओं में नहीं लाया जाता है ... एक परीक्षक का दुःस्वप्न। चूंकि बहुत सारी रूपरेखाएँ हैं, आप अपने एड-ऑन लिखे बिना भी परीक्षण (टीडीडी) के माध्यम से विकास को सही ढंग से लागू नहीं कर सकते हैं और वस्तुओं, सत्रों, कुकीज़ को संसाधित करने और इनपुट नियंत्रक (फ्रंट कंट्रोलर रीसेट) को रीसेट करने की आवश्यकता है। और यहां तक ​​कि इस मामले में, आपको नियंत्रक द्वारा बनाए गए दृश्य का परीक्षण करना होगा, क्योंकि इसमें कोई आउटपुट तरीके नहीं हैं जो विचारों से स्वतंत्र हैं!

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

मॉडल अपरिहार्य हैं (मृत्यु और करों की तरह)

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

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

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

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

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

नियंत्रकों को डेटा की सुरक्षा नहीं करनी चाहिए

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

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

मेरे लिए सबसे अच्छा नियंत्रक एक नियंत्रक की कमी है।

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

नोट: सब कुछ इतना बुरा नहीं है - कुछ लोग समझ गए कि वे किस बारे में बात कर रहे थे।

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

तो आगे क्यों नहीं जाना! एक मॉडल के लिए कितने विचार पर्याप्त हैं? मेरे कई विचार कई मॉडल का उपयोग करते हैं, जिनमें से कॉल अक्सर दोहराए जाते हैं। व्यू हेल्पर एक वर्ग है, लेकिन नियंत्रक को दोहराई जाने वाली कॉल जोड़ने के लिए, हमें इन कॉल को कई तरीकों से दोहराना होगा!

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

मॉडल - कक्षाएं, नियंत्रक - प्रक्रियाएं

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

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

एक बार फिर, नियंत्रक क्लचिंग एक स्टॉक कोड है। यह अक्षम, अनाड़ी है, और आमतौर पर इसकी आवश्यकता नहीं है।

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

मूल विचार यह है कि एक मॉडल केवल शिथिल युग्मित वर्गों का एक संग्रह है। आप अपने उदाहरण कहीं भी बना सकते हैं और उनका उपयोग कर सकते हैं - अन्य मॉडलों, नियंत्रकों और यहां तक ​​कि विचारों में भी! दूसरी ओर नियंत्रक, समग्र प्रक्रिया का एक अभिन्न अंग है। आप अनुरोध ऑब्जेक्ट्स बनाने, प्रेषण, कार्रवाई सहायकों का उपयोग करने, प्रस्तुति को आरम्भ करने और लौटी प्रतिक्रिया वस्तुओं को संसाधित करने की पूरी प्रक्रिया शुरू किए बिना नियंत्रक का पुन: उपयोग नहीं कर सकते। यह महंगा और अजीब है।

बातचीत के अंत में

जैसा कि आपने देखा होगा, यह लेख महत्वपूर्ण था। मैं MVC फ्रेमवर्क में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के सुरुचिपूर्ण सिद्धांतों को लागू करने की आवश्यकता के बारे में दृढ़ता से आश्वस्त हूं। यही वजह है कि मैंने Zend_View एन्हांसमेंट को Zend फ्रेमवर्क में प्रमोट करने की पूरी कोशिश की और देखा कि कैसे इसे मंजूरी, चर्चा और बेहद सफलतापूर्वक इस्तेमाल किया गया। यह काफी हद तक मैथ्यू वीयर ओ'पनी और राल्फ शिंडलर के कारण था, जो इस विचार को बढ़ावा देने में शामिल हुए। ओओपी के सरल तरीकों और सिद्धांतों के बारे में भूलकर, हम एमवीसी के खिलाफ लड़ाई में फंस जाएंगे, इसके अर्थ के बारे में भूल जाएंगे। एमवीसी एक महान वास्तुशिल्प टेम्पलेट है, लेकिन अंत में, एमवीसी और आम धारणाओं की हमारी कोई भी व्याख्या ओओपी सिद्धांतों से ली गई है। इसके बारे में भूलकर, हम बैड थिंग्स (टीएम) करना शुरू कर देंगे।

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

द एम इन एमवीसी: व्हाई मॉडल्स मिसअंडरस्टूड एंड अनअप्रूव्ड