एमवीसी वास्तुकला का परिचय
सबसे लोकप्रिय एप्लिकेशन आर्किटेक्चर जिसके बारे में हर प्रोग्रामर जानता है वह एमवीसी है । MVC का मतलब मॉडल-व्यू-कंट्रोलर है ।
यह एप्लिकेशन आर्किटेक्चर के रूप में एप्लिकेशन घटकों के आर्किटेक्चर के रूप में इतना अधिक नहीं है, लेकिन हम इस बारीकियों पर बाद में लौटेंगे। एमवीसी क्या है?
एमवीसी एप्लिकेशन डेटा और कंट्रोल लॉजिक को तीन अलग-अलग घटकों- मॉडल, व्यू और कंट्रोलर में अलग करने की योजना है , ताकि प्रत्येक घटक को स्वतंत्र रूप से संशोधित किया जा सके।
- मॉडल (मॉडल) अपनी स्थिति बदलकर डेटा प्रदान करता है और नियंत्रक आदेशों का जवाब देता है।
- मॉडल परिवर्तन के जवाब में उपयोगकर्ता को मॉडल डेटा प्रदर्शित करने के लिए दृश्य जिम्मेदार है।
- नियंत्रक (नियंत्रक) परिवर्तन की आवश्यकता के मॉडल को सूचित करते हुए, उपयोगकर्ता के कार्यों की व्याख्या करता है।
इस मॉडल का आविष्कार 1978 (!) वर्ष में किया गया था। हां, 50 साल पहले उचित सॉफ्टवेयर आर्किटेक्चर के साथ समस्याएं प्रासंगिक थीं। यहाँ बताया गया है कि इस मॉडल को मूल चित्र में कैसे वर्णित किया गया है:
मॉडल उनके साथ काम करने के लिए डेटा और तरीके प्रदान करता है: डेटाबेस के लिए प्रश्न, शुद्धता की जाँच। मॉडल दृश्य से स्वतंत्र है (डेटा को प्रस्तुत करना नहीं जानता है) और नियंत्रक (उपयोगकर्ता इंटरैक्शन पॉइंट नहीं है), डेटा तक पहुंच और प्रबंधन प्रदान करता है।
मॉडल को इस तरह से बनाया गया है कि इसकी स्थिति को बदलकर अनुरोधों का जवाब दिया जा सकता है, और "पर्यवेक्षकों" की अधिसूचना में बनाया जा सकता है। दृश्य प्रतिनिधित्व से स्वतंत्र होने के कारण मॉडल में एक "मॉडल" के लिए कई अलग-अलग प्रतिनिधित्व हो सकते हैं ।
मॉडल से आवश्यक डेटा प्राप्त करने और इसे उपयोगकर्ता को भेजने के लिए दृश्य जिम्मेदार है। दृश्य उपयोगकर्ता इनपुट को संसाधित नहीं करता है।
नियंत्रक उपयोगकर्ता और सिस्टम के बीच "संचार" प्रदान करता है। उपयोगकर्ता से सिस्टम तक और इसके विपरीत डेटा को नियंत्रित और निर्देशित करता है। वांछित कार्रवाई को लागू करने के लिए एक मॉडल और एक दृश्य का उपयोग करता है।
इस तथ्य के साथ एक निश्चित कठिनाई है कि यह मॉडल दशकों में थोड़ा विकसित हुआ है। यानी नाम वही रहा, लेकिन भागों का उद्देश्य बदलने लगा।
वेब पर एमवीसी आर्किटेक्चर
एमवीसी डिजाइन पैटर्न के पीछे का विचार बहुत सरल है: हमें अपने अनुप्रयोगों में विभिन्न व्यवहारों के लिए जिम्मेदारी को स्पष्ट रूप से अलग करने की आवश्यकता है:
नमूना- डेटा प्रोसेसिंग और एप्लिकेशन लॉजिक।
देखना- उपयोगकर्ता को किसी भी समर्थित प्रारूप में डेटा प्रदान करना।
नियंत्रक- उपयोगकर्ता अनुरोधों को संसाधित करना और उपयुक्त संसाधनों को कॉल करना।
एप्लिकेशन को तीन मुख्य घटकों में विभाजित किया गया है, जिनमें से प्रत्येक विभिन्न कार्यों के लिए जिम्मेदार है। आइए एक उदाहरण का उपयोग करके क्लाइंट-सर्वर एप्लिकेशन के घटकों पर करीब से नज़र डालें।
नियंत्रक
उपयोगकर्ता ब्राउज़र में पृष्ठ पर विभिन्न तत्वों पर क्लिक करता है, जिसके परिणामस्वरूप ब्राउज़र विभिन्न HTTP अनुरोध भेजता है: GET, POST, या अन्य। नियंत्रक ब्राउज़र और जेएस कोड शामिल कर सकता है जो पृष्ठ के अंदर काम करता है।
इस मामले में नियंत्रक का मुख्य कार्य आवश्यक वस्तुओं पर विधियों को कॉल करना है, उपयोगकर्ता द्वारा निर्दिष्ट कार्यों को करने के लिए संसाधनों तक पहुंच का प्रबंधन करना है। विशिष्ट रूप से, नियंत्रक कार्य के लिए उपयुक्त मॉडल को कॉल करता है और उपयुक्त दृश्य का चयन करता है।
नमूना
एक व्यापक अर्थ में मॉडल डेटा और नियम हैं जो डेटा के साथ काम करने के लिए उपयोग किए जाते हैं - साथ में वे एप्लिकेशन के व्यावसायिक तर्क को बनाते हैं। किसी एप्लिकेशन को डिजाइन करना हमेशा उन वस्तुओं के मॉडल के निर्माण से शुरू होता है जिन पर वह काम करता है।
मान लीजिए कि हमारा एक ऑनलाइन स्टोर है जो किताबें बेचता है, तो क्या एक व्यक्ति केवल एक एप्लिकेशन उपयोगकर्ता है या एक पुस्तक का लेखक भी है? मॉडल डिजाइन के दौरान इन महत्वपूर्ण प्रश्नों को संबोधित किया जाना चाहिए।
इसके अलावा नियमों के समूह हैं: क्या किया जा सकता है, क्या नहीं किया जा सकता, कौन से डेटा सेट स्वीकार्य हैं और कौन से नहीं। क्या बिना लेखक के कोई किताब हो सकती है? और किताबों के बिना लेखक? क्या उपयोगकर्ता की जन्म तिथि वर्ष 300 और इसी तरह हो सकती है।
मॉडल नियंत्रक को उपयोगकर्ता द्वारा अनुरोधित डेटा (संदेश, पुस्तक पृष्ठ, चित्र, आदि) का एक दृश्य देता है। डेटा मॉडल वही रहेगा चाहे हम इसे उपयोगकर्ता को कैसे प्रस्तुत करना चाहते हैं। इसलिए, हम डेटा प्रदर्शित करने के लिए कोई भी उपलब्ध दृश्य चुनते हैं।
मॉडल में हमारे एप्लिकेशन लॉजिक का सबसे महत्वपूर्ण हिस्सा होता है , वह तर्क जो उस समस्या को हल करता है जिससे हम निपट रहे हैं (फोरम, दुकान, बैंक, आदि)। नियंत्रक में ज्यादातर एप्लिकेशन के लिए संगठनात्मक तर्क होते हैं (बिल्कुल आपके प्रोजेक्ट मैनेजर की तरह)।
देखना
दृश्य मॉडल से प्राप्त होने वाले डेटा का प्रतिनिधित्व करने के विभिन्न तरीके प्रदान करता है। यह एक टेम्प्लेट हो सकता है जो डेटा से भरा हो। कई अलग-अलग विचार हो सकते हैं और नियंत्रक चुनता है कि वर्तमान स्थिति के लिए कौन सा सबसे अच्छा है।
एक वेब एप्लिकेशन में आमतौर पर नियंत्रकों, मॉडलों और विचारों का एक सेट होता है। नियंत्रक केवल बैकएंड पर हो सकता है, लेकिन कई नियंत्रकों का एक प्रकार भी हो सकता है, जब इसका तर्क फ्रंटएंड पर भी फैला हो। इस दृष्टिकोण का एक अच्छा उदाहरण कोई भी मोबाइल एप्लिकेशन है।
वेब पर एमवीसी उदाहरण
मान लीजिए कि आपको एक ऑनलाइन स्टोर विकसित करने की आवश्यकता है जो किताबें बेचेगा। उपयोगकर्ता निम्नलिखित क्रियाएं कर सकता है: किताबें देखें, रजिस्टर करें, खरीदें, मौजूदा ऑर्डर में आइटम जोड़ें, अपनी पसंद की किताबों को चिह्नित करें और उन्हें खरीदें।
आपके एप्लिकेशन में ऐसा मॉडल होना चाहिए जो सभी व्यावसायिक तर्कों के लिए ज़िम्मेदार हो। आपको एक नियंत्रक की भी आवश्यकता है जो सभी उपयोगकर्ता क्रियाओं को संसाधित करेगा और उन्हें व्यावसायिक तर्क से विधि कॉल में बदल देगा। हालाँकि, एक नियंत्रक विधि कई अलग-अलग मॉडल विधियों को कॉल कर सकती है।
आपको दृश्यों के सेट की भी आवश्यकता है: पुस्तकों की सूची, एक पुस्तक के बारे में जानकारी, शॉपिंग कार्ट, आदेशों की सूची। वेब एप्लिकेशन का प्रत्येक पृष्ठ वास्तव में एक अलग दृश्य है जो उपयोगकर्ता को मॉडल के एक निश्चित पहलू को प्रदर्शित करता है।
आइए देखें कि क्या होता है यदि कोई उपयोगकर्ता शीर्षक देखने के लिए बुकस्टोर अनुशंसित पुस्तकों की सूची खोलता है। क्रियाओं के पूरे क्रम को 6 चरणों के रूप में वर्णित किया जा सकता है:
कदम:
- उपयोगकर्ता "अनुशंसित" लिंक पर क्लिक करता है और ब्राउज़र /पुस्तकों/सिफारिशों के लिए अनुरोध भेजता है ।
- नियंत्रक अनुरोध की जाँच करता है : उपयोगकर्ता को लॉग इन होना चाहिए। या हमारे पास गैर-लॉग इन उपयोगकर्ताओं के लिए पुस्तकों का संग्रह होना चाहिए। नियंत्रक तब मॉडल को कॉल करता है और उपयोगकर्ता एन को अनुशंसित पुस्तकों की सूची वापस करने के लिए कहता है।
- मॉडल डेटाबेस तक पहुँचता है, वहाँ से पुस्तकों के बारे में जानकारी प्राप्त करता है: पुस्तकें जो वर्तमान में लोकप्रिय हैं, उपयोगकर्ता द्वारा खरीदी गई पुस्तकें, उसके दोस्तों द्वारा खरीदी गई पुस्तकें, उसकी इच्छा सूची से पुस्तकें। इस डेटा के आधार पर, मॉडल 10 अनुशंसित पुस्तकों की सूची बनाता है और उन्हें नियंत्रक को लौटाता है।
- नियंत्रक अनुशंसित पुस्तकों की एक सूची प्राप्त करता है और इसे देखता है। इस स्तर पर, नियंत्रक निर्णय लेता है! यदि कुछ पुस्तकें हैं या सूची पूरी तरह खाली है, तो यह अनलॉग किए गए उपयोगकर्ता के लिए पुस्तकों की सूची का अनुरोध करता है। यदि अभी कोई प्रचार चल रहा है, तो नियंत्रक प्रचार पुस्तकों को सूची में जोड़ सकता है।
- नियंत्रक निर्धारित करता है कि उपयोगकर्ता को कौन सा पृष्ठ दिखाना है। यह एक त्रुटि पृष्ठ हो सकता है, पुस्तकों की सूची वाला पृष्ठ, बधाई देने वाला पृष्ठ कि उपयोगकर्ता दस लाखवाँ आगंतुक बन गया है।
- सर्वर क्लाइंट को नियंत्रक द्वारा चयनित पृष्ठ ( देखें ) देता है। यह आवश्यक डेटा (उपयोगकर्ता नाम, पुस्तकों की सूची) से भर जाता है और ग्राहक के पास जाता है।
- क्लाइंट पृष्ठ प्राप्त करता है और इसे उपयोगकर्ता को प्रदर्शित करता है।
इस दृष्टिकोण के क्या लाभ हैं?
एमवीसी अवधारणा का उपयोग करने से हमें जो सबसे स्पष्ट लाभ मिलता है, वह प्रस्तुति तर्क (उपयोगकर्ता इंटरफ़ेस) और अनुप्रयोग तर्क (बैकएंड) का स्पष्ट पृथक्करण है।
दूसरा लाभ सर्वर भाग का दो में विभाजन है: एक स्मार्ट मॉडल ( निष्पादक ) और एक नियंत्रक ( निर्णय केंद्र )।
पिछले उदाहरण में, एक क्षण था जब नियंत्रक मॉडल से अनुशंसित पुस्तकों की एक खाली सूची प्राप्त कर सकता था और तय कर सकता था कि इसके साथ क्या करना है। सैद्धांतिक रूप से, इस तर्क को सीधे मॉडल में डाला जा सकता है।
सबसे पहले, अनुशंसित पुस्तकों का अनुरोध करते समय, मॉडल तय करेगा कि सूची खाली होने पर क्या करना है। फिर मुझे उसी जगह कोड जोड़ना होगा, अगर अभी प्रमोशन चल रहा है तो क्या करें, और भी अलग-अलग विकल्प।
फिर यह पता चला कि स्टोर व्यवस्थापक यह देखना चाहता था कि बिना प्रचार के उपयोगकर्ता का पृष्ठ कैसा दिखेगा, या इसके विपरीत, अब कोई प्रचार नहीं है, लेकिन वह देखना चाहता है कि भविष्य का प्रचार कैसे प्रदर्शित होगा। और इसके लिए कोई उपाय नहीं हैं। इसलिए, निर्णय केंद्र (नियंत्रक) को व्यावसायिक तर्क (मॉडल) से अलग करने का निर्णय लिया गया।
अनुप्रयोग तर्क से विचारों को अलग करने के अलावा, MVC अवधारणा बड़े अनुप्रयोगों की जटिलता को बहुत कम कर देती है। कोड बहुत अधिक संरचित है, जिससे समाधान को बनाए रखना, परीक्षण करना और पुन: उपयोग करना आसान हो जाता है।
एमवीसी की अवधारणा को समझते हुए, आप, एक डेवलपर के रूप में, महसूस करते हैं कि आपको पुस्तकों की सूची को क्रमबद्ध करने के लिए कहाँ जोड़ने की आवश्यकता है:
- डेटाबेस क्वेरी स्तर पर।
- व्यापार तर्क (मॉडल) के स्तर पर।
- व्यापार तर्क स्तर (नियंत्रक) पर।
- दृश्य में - ग्राहक पक्ष पर।
और यह कोई अलंकारिक प्रश्न नहीं है। अभी, इस बारे में सोचें कि पुस्तकों की सूची को क्रमबद्ध करने के लिए आपको कहाँ और क्यों कोड जोड़ने की आवश्यकता है।
क्लासिक एमवीसी मॉडल
वेब एप्लिकेशन और मोबाइल एप्लिकेशन में MVC घटकों के बीच सहभागिता को अलग तरीके से कार्यान्वित किया जाता है। ऐसा इसलिए है क्योंकि वेब ऐप अल्पकालिक है, एक उपयोगकर्ता के अनुरोध को संसाधित करता है और बाहर निकल जाता है, जबकि मोबाइल ऐप बिना पुनरारंभ किए कई अनुरोधों को संसाधित करता है।
वेब एप्लिकेशन आमतौर पर "निष्क्रिय" मॉडल का उपयोग करते हैं, जबकि मोबाइल एप्लिकेशन "सक्रिय" मॉडल का उपयोग करते हैं। सक्रिय मॉडल, निष्क्रिय के विपरीत, आपको इसमें परिवर्तन की सदस्यता लेने और सूचनाएं प्राप्त करने की अनुमति देता है। वेब एप्लिकेशन के लिए यह आवश्यक नहीं है।
विभिन्न मॉडलों में घटकों की परस्पर क्रिया इस प्रकार दिखती है:
मोबाइल एप्लिकेशन (सक्रिय मॉडल) सक्रिय रूप से ईवेंट और ईवेंट सदस्यता तंत्र का उपयोग करते हैं। इस दृष्टिकोण के साथ, देखें ( दृश्य ) मॉडल परिवर्तनों की सदस्यता लेता है। फिर, जब कोई घटना होती है (उदाहरण के लिए, उपयोगकर्ता एक बटन क्लिक करता है), नियंत्रक को कहा जाता है । यह मॉडल को डेटा बदलने का कमांड भी देता है।
यदि कुछ डेटा बदल गया है, तो मॉडल इस डेटा को बदलने के बारे में एक ईवेंट उत्पन्न करता है। सभी दृश्य जिन्होंने इस घटना की सदस्यता ली है (जिसके लिए इस विशेष डेटा को बदलना महत्वपूर्ण है) इस घटना को प्राप्त करते हैं और डेटा को अपने इंटरफ़ेस में अपडेट करते हैं।
वेब एप्लिकेशन में, चीजों को थोड़ा अलग तरीके से व्यवस्थित किया जाता है। मुख्य तकनीकी अंतर यह है कि क्लाइंट सर्वर की पहल पर सर्वर-साइड संदेश प्राप्त नहीं कर सकता है ।
इसलिए, एक वेब एप्लिकेशन में एक नियंत्रक आमतौर पर दृश्य को कोई संदेश नहीं भेजता है, लेकिन ग्राहक को एक नया पृष्ठ देता है, जो तकनीकी रूप से एक नया दृश्य या एक नया ग्राहक अनुप्रयोग है (यदि एक पृष्ठ दूसरे के बारे में कुछ नहीं जानता है) .
वर्तमान समय में, निम्नलिखित दृष्टिकोणों का उपयोग करके इस समस्या को आंशिक रूप से हल किया गया है:
- महत्वपूर्ण डेटा में परिवर्तन के लिए नियमित रूप से सर्वर की पोलिंग करना (एक मिनट या अधिक बार)।
- वेबसाकेट क्लाइंट को सर्वर संदेशों की सदस्यता लेने की अनुमति देता है।
- सर्वर साइड से वेब पुश सूचनाएँ।
- HTTP/2 प्रोटोकॉल सर्वर को क्लाइंट को संदेश भेजने की शुरुआत करने की अनुमति देता है।