क्या यह MVC है?

शुभ दोपहर

आज मैं आपके साथ सूचना प्रणाली की वास्तुकला पर अपने विचार साझा करना चाहता हूं, विशेष रूप से, तर्क के आधार पर विविध दृष्टिकोण, डेटा और प्रदर्शन, पारंपरिक रूप से MVC के लिए जिम्मेदार हैं।

पिछले दो हफ्तों में, एक दर्जन परिचित प्रोग्रामर के साथ बातचीत में, मुझे पता चला कि हर कोई एमवीसी की पूरी तरह से कल्पना करता है। यह बेहद विरोधाभासी विचारों के साथ आता है, लेकिन किसी कारण से, हर कोई इस बात पर जोर देता है कि यह एमवीसी है और इसे इस तरह से देखना चाहिए, और पूरी तरह से आश्वस्त हैं कि हर कोई इसे इसी तरह से देखता है।

अंतर क्या है? इसे समझने के लिए, आइए MVC के कार्यों को तैयार करें:

1. मॉडल को स्क्रीन करें - अर्थात, यह सुनिश्चित करें कि एप्लिकेशन के तकनीकी कार्यान्वयन, उपयोगकर्ता इंटरफ़ेस, नेटवर्क प्रोटोकॉल, डेटाबेस और यहां तक ​​कि सिस्टम आर्किटेक्चर के साथ काम करने के बारे में मॉडल को "पता" नहीं है। मॉडल को विषय क्षेत्र को प्रतिबिंबित करना चाहिए और प्रौद्योगिकी से बाहर होना चाहिए।

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

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

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

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

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

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

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

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

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



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

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

आपका ध्यान देने के लिए धन्यवाद।