MVC आर्किटेक्चरचा परिचय
प्रत्येक प्रोग्रामरला माहित असलेले सर्वात लोकप्रिय अॅप्लिकेशन आर्किटेक्चर म्हणजे MVC . MVC म्हणजे मॉडेल-व्ह्यू-कंट्रोलर .
हे अनुप्रयोग घटकांच्या आर्किटेक्चरसारखे अनुप्रयोगांचे आर्किटेक्चर नाही, परंतु आम्ही नंतर या सूक्ष्मतेकडे परत येऊ. MVC म्हणजे काय?
MVC ही अॅप्लिकेशन डेटा आणि कंट्रोल लॉजिक तीन स्वतंत्र घटकांमध्ये विभक्त करण्याची योजना आहे- मॉडेल, व्ह्यू आणि कंट्रोलर — जेणेकरून प्रत्येक घटक स्वतंत्रपणे सुधारला जाऊ शकतो.
- मॉडेल (मॉडेल) डेटा प्रदान करते आणि त्याची स्थिती बदलून नियंत्रक आदेशांना प्रतिसाद देते.
- मॉडेल बदलांना प्रतिसाद म्हणून वापरकर्त्याला मॉडेल डेटा प्रदर्शित करण्यासाठी दृश्य जबाबदार आहे.
- कंट्रोलर (नियंत्रक) वापरकर्त्याच्या कृतींचा अर्थ लावतो, बदलांची आवश्यकता मॉडेलला सूचित करतो.
या मॉडेलचा शोध 1978 (!) वर्षात लागला होता. होय, योग्य सॉफ्टवेअर आर्किटेक्चरसह समस्या 50 वर्षांपूर्वी संबंधित होत्या. या मॉडेलचे मूळ आकृतीमध्ये कसे वर्णन केले आहे ते येथे आहे:
मॉडेल त्यांच्यासह कार्य करण्यासाठी डेटा आणि पद्धती प्रदान करते: डेटाबेससाठी क्वेरी, शुद्धता तपासणे. मॉडेल दृश्यापासून स्वतंत्र आहे (डेटा रेंडर कसा करायचा हे माहित नाही) आणि कंट्रोलर (वापरकर्ता परस्परसंवाद बिंदू नाहीत), डेटामध्ये प्रवेश आणि व्यवस्थापन प्रदान करते.
मॉडेल अशा प्रकारे तयार केले आहे की त्याची स्थिती बदलून विनंत्यांना प्रतिसाद द्यावा आणि "निरीक्षक" ची सूचना तयार केली जाऊ शकते. मॉडेल, व्हिज्युअल प्रतिनिधित्वापासून स्वातंत्र्यामुळे, एका "मॉडेल" साठी अनेक भिन्न प्रतिनिधित्व असू शकतात .
मॉडेलमधून आवश्यक डेटा मिळविण्यासाठी आणि वापरकर्त्याला पाठविण्यासाठी दृश्य जबाबदार आहे. दृश्य वापरकर्त्याच्या इनपुटवर प्रक्रिया करत नाही.
कंट्रोलर वापरकर्ता आणि सिस्टम दरम्यान "संवाद" प्रदान करतो. वापरकर्त्याकडून सिस्टमकडे डेटा नियंत्रित आणि निर्देशित करते आणि त्याउलट. इच्छित कृती अंमलात आणण्यासाठी मॉडेल आणि दृश्य वापरते.
हे मॉडेल काही दशकांमध्ये विकसित झाले आहे या वस्तुस्थितीत एक विशिष्ट अडचण आहे. म्हणजेच, नाव तेच राहिले, परंतु भागांचे प्रयोजन बदलू लागले.
वेबवर MVC आर्किटेक्चर
MVC डिझाइन पॅटर्नमागील कल्पना अगदी सोपी आहे: आम्हाला आमच्या ऍप्लिकेशन्समधील वेगवेगळ्या वर्तनांसाठी जबाबदारी स्पष्टपणे विभक्त करणे आवश्यक आहे:
मॉडेल- डेटा प्रोसेसिंग आणि ऍप्लिकेशन लॉजिक.
दृश्य— वापरकर्त्याला कोणत्याही समर्थित स्वरूपात डेटा प्रदान करणे.
नियंत्रक- वापरकर्त्याच्या विनंतीवर प्रक्रिया करणे आणि योग्य संसाधनांना कॉल करणे.
अनुप्रयोग तीन मुख्य घटकांमध्ये विभागलेला आहे, त्यापैकी प्रत्येक वेगवेगळ्या कार्यांसाठी जबाबदार आहे. उदाहरण वापरून क्लायंट-सर्व्हर ऍप्लिकेशनचे घटक जवळून पाहू.
नियंत्रक
वापरकर्ता ब्राउझरमधील पृष्ठावरील विविध घटकांवर क्लिक करतो, परिणामी ब्राउझर विविध HTTP विनंत्या पाठवतो: GET, POST किंवा इतर. नियंत्रक ब्राउझर आणि जेएस कोड समाविष्ट करू शकतो जे पृष्ठाच्या आत कार्य करतात.
या प्रकरणात नियंत्रकाचे मुख्य कार्य म्हणजे आवश्यक वस्तूंवर पद्धती कॉल करणे, वापरकर्त्याने निर्दिष्ट केलेली कार्ये करण्यासाठी संसाधनांमध्ये प्रवेश व्यवस्थापित करणे. सामान्यतः, नियंत्रक कार्यासाठी योग्य मॉडेलला कॉल करतो आणि योग्य दृश्य निवडतो.
मॉडेल
विस्तृत अर्थाने मॉडेल म्हणजे डेटा आणि नियम जे डेटासह कार्य करण्यासाठी वापरले जातात - एकत्रितपणे ते अनुप्रयोगाचे व्यावसायिक तर्क तयार करतात. एखादे अॅप्लिकेशन डिझाईन करणे हे नेहमी ते ऑपरेट करत असलेल्या वस्तूंच्या बिल्डिंग मॉडेलपासून सुरू होते.
समजा आमच्याकडे पुस्तके विकणारे ऑनलाइन स्टोअर आहे, मग एखादी व्यक्ती फक्त ऍप्लिकेशन वापरकर्ता आहे की एखाद्या पुस्तकाचा लेखक देखील आहे? मॉडेल डिझाइन दरम्यान या महत्त्वपूर्ण प्रश्नांकडे लक्ष देणे आवश्यक आहे.
पुढे नियमांचे संच आहेत: काय केले जाऊ शकते, काय केले जाऊ शकत नाही, कोणते डेटा संच स्वीकार्य आहेत आणि कोणते नाहीत. लेखकाशिवाय पुस्तक अस्तित्वात असू शकते का? आणि पुस्तकांशिवाय लेखक? वापरकर्त्याची जन्मतारीख 300 सालची असू शकते का.
मॉडेल कंट्रोलरला वापरकर्त्याने विनंती केलेल्या डेटाचे दृश्य देते (संदेश, पुस्तक पृष्ठ, चित्रे इ.). डेटा मॉडेल आम्ही वापरकर्त्याला कसे सादर करू इच्छितो हे महत्त्वाचे नाही. म्हणून, डेटा प्रदर्शित करण्यासाठी आम्ही कोणतेही उपलब्ध दृश्य निवडतो.
मॉडेलमध्ये आमच्या ऍप्लिकेशन लॉजिकचा सर्वात महत्त्वाचा भाग आहे , लॉजिक जे आम्ही हाताळत असलेल्या समस्येचे निराकरण करते (फोरम, दुकान, बँक इ.). कंट्रोलरमध्ये ऍप्लिकेशनसाठी मुख्यतः संस्थात्मक तर्क असतो (जसे तुमच्या प्रोजेक्ट मॅनेजरप्रमाणे).
पहा
मॉडेलमधून प्राप्त झालेल्या डेटाचे प्रतिनिधित्व करण्यासाठी दृश्य विविध मार्ग प्रदान करते. हे डेटाने भरलेले टेम्पलेट असू शकते. अनेक भिन्न दृश्ये असू शकतात आणि सध्याच्या परिस्थितीसाठी कोणता सर्वोत्तम आहे ते नियंत्रक निवडतो.
वेब अॅप्लिकेशनमध्ये सहसा कंट्रोलर, मॉडेल्स आणि व्ह्यूजचा संच असतो. कंट्रोलर फक्त बॅकएंडवर असू शकतो, परंतु त्याचे लॉजिक फ्रंटएंडवर देखील पसरलेले असताना अनेक कंट्रोलरचे एक प्रकार देखील असू शकतात. या दृष्टिकोनाचे एक चांगले उदाहरण कोणतेही मोबाइल अनुप्रयोग आहे.
वेबवरील MVC उदाहरण
समजा तुम्हाला एक ऑनलाइन स्टोअर विकसित करणे आवश्यक आहे जे पुस्तके विकेल. वापरकर्ता खालील क्रिया करू शकतो: पुस्तके पहा, नोंदणी करा, खरेदी करा, वर्तमान ऑर्डरमध्ये आयटम जोडा, त्याला आवडणारी पुस्तके चिन्हांकित करा आणि ती खरेदी करा.
तुमच्या अर्जामध्ये सर्व व्यावसायिक तर्कांसाठी जबाबदार असलेले मॉडेल असावे . तुम्हाला एका नियंत्रकाची देखील आवश्यकता आहे जो वापरकर्त्याच्या सर्व क्रियांवर प्रक्रिया करेल आणि त्यांना व्यवसाय तर्कशास्त्रातील मेथड कॉलमध्ये बदलेल. तथापि, एक नियंत्रक पद्धत अनेक भिन्न मॉडेल पद्धती कॉल करू शकते.
आपल्याला दृश्यांचे संच देखील आवश्यक आहेत: पुस्तकांची सूची, एका पुस्तकाची माहिती, शॉपिंग कार्ट, ऑर्डरची सूची. वेब ऍप्लिकेशनचे प्रत्येक पृष्ठ हे प्रत्यक्षात एक वेगळे दृश्य आहे जे वापरकर्त्यास मॉडेलचे विशिष्ट पैलू प्रदर्शित करते.
शीर्षक पाहण्यासाठी वापरकर्त्याने पुस्तकांच्या दुकानात शिफारस केलेल्या पुस्तकांची सूची उघडल्यास काय होते ते पाहू या. क्रियांचा संपूर्ण क्रम 6 चरणांच्या स्वरूपात वर्णन केला जाऊ शकतो:
पायऱ्या:
- वापरकर्ता "शिफारस केलेल्या" लिंकवर क्लिक करतो आणि ब्राउझर /books/recommendations ला विनंती पाठवतो .
- कंट्रोलर विनंती तपासतो : वापरकर्त्याने लॉग इन केले पाहिजे. किंवा आमच्याकडे लॉग इन नसलेल्या वापरकर्त्यांसाठी पुस्तकांचा संग्रह असावा. नियंत्रक नंतर मॉडेलला कॉल करतो आणि वापरकर्त्यास N ला शिफारस केलेल्या पुस्तकांची यादी परत करण्यास सांगतो.
- मॉडेल डेटाबेसमध्ये प्रवेश करते, तेथून पुस्तकांबद्दल माहिती पुनर्प्राप्त करते: सध्या लोकप्रिय असलेली पुस्तके, वापरकर्त्याने विकत घेतलेली पुस्तके, त्याच्या मित्रांनी विकत घेतलेली पुस्तके, त्याच्या इच्छा यादीतील पुस्तके. या डेटाच्या आधारे, मॉडेल 10 शिफारस केलेल्या पुस्तकांची सूची तयार करते आणि त्यांना नियंत्रकाकडे परत करते.
- नियंत्रकाला शिफारस केलेल्या पुस्तकांची यादी मिळते आणि ती पाहतो. या टप्प्यावर, नियंत्रक निर्णय घेतो! जर काही पुस्तके असतील किंवा यादी पूर्णपणे रिकामी असेल, तर ते अनलॉग केलेल्या वापरकर्त्यासाठी पुस्तकांच्या सूचीची विनंती करते. आत्ता प्रमोशन चालू असल्यास, कंट्रोलर सूचीमध्ये प्रचारात्मक पुस्तके जोडू शकतो.
- वापरकर्त्याला कोणते पृष्ठ दाखवायचे ते नियंत्रक ठरवतो. हे एक त्रुटी पृष्ठ असू शकते, पुस्तकांच्या सूचीसह एक पृष्ठ, वापरकर्ता लाखवा अभ्यागत बनल्याचे अभिनंदन करणारे पृष्ठ असू शकते.
- सर्व्हर क्लायंटला कंट्रोलरने निवडलेले पृष्ठ ( दृश्य ) देतो. हे आवश्यक डेटा (वापरकर्तानाव, पुस्तकांची सूची) भरले आहे आणि क्लायंटकडे जाते.
- क्लायंटला पृष्ठ प्राप्त होते आणि ते वापरकर्त्यास प्रदर्शित करते.
या दृष्टिकोनाचे फायदे काय आहेत?
MVC संकल्पना वापरून आम्हाला मिळणारा सर्वात स्पष्ट फायदा म्हणजे प्रेझेंटेशन लॉजिक (वापरकर्ता इंटरफेस) आणि ऍप्लिकेशन लॉजिक (बॅकएंड) यांचे स्पष्ट पृथक्करण.
दुसरा फायदा म्हणजे सर्व्हरच्या भागाचे दोन भागांमध्ये विभाजन करणे: एक स्मार्ट मॉडेल ( एक्झिक्यूटर ) आणि कंट्रोलर ( निर्णय केंद्र ).
मागील उदाहरणामध्ये, एक क्षण असा होता जेव्हा नियंत्रक मॉडेलकडून शिफारस केलेल्या पुस्तकांची रिक्त यादी प्राप्त करू शकतो आणि त्याचे काय करायचे ते ठरवू शकतो. सैद्धांतिकदृष्ट्या, हे तर्क थेट मॉडेलमध्ये ठेवले जाऊ शकते.
प्रथम, शिफारस केलेल्या पुस्तकांची विनंती करताना, यादी रिकामी असल्यास काय करायचे हे मॉडेल ठरवेल. मग मला त्याच ठिकाणी कोड जोडावा लागेल, आता प्रमोशन चालू असेल तर काय करावे, नंतर आणखी भिन्न पर्याय.
मग असे दिसून आले की स्टोअर प्रशासकास जाहिरातीशिवाय वापरकर्त्याचे पृष्ठ कसे दिसेल हे पहायचे आहे किंवा त्याउलट, आता कोणतीही जाहिरात नाही, परंतु भविष्यातील जाहिरात कशी प्रदर्शित केली जाईल हे त्याला पहायचे आहे. आणि यासाठी कोणत्याही पद्धती नाहीत. म्हणून, निर्णय केंद्र (नियंत्रक) व्यवसाय तर्कशास्त्र (मॉडेल) पासून वेगळे करण्याचा निर्णय घेण्यात आला.
ऍप्लिकेशन लॉजिकमधून दृश्य वेगळे करण्याव्यतिरिक्त, MVC संकल्पना मोठ्या ऍप्लिकेशन्सची जटिलता मोठ्या प्रमाणात कमी करते. कोड अधिक संरचित आहे, ज्यामुळे उपायांची देखभाल करणे, चाचणी करणे आणि पुनर्वापर करणे सोपे होते.
MVC ची संकल्पना समजून घेताना, विकसक म्हणून, तुम्हाला पुस्तकांची यादी कुठे जोडायची आहे हे लक्षात येते:
- डेटाबेस क्वेरी स्तरावर.
- व्यवसाय तर्कशास्त्र (मॉडेल) च्या पातळीवर.
- व्यवसाय तर्क पातळीवर (नियंत्रक).
- दृश्यात - क्लायंटच्या बाजूने.
आणि हा वक्तृत्वाचा प्रश्न नाही. आत्ताच, पुस्तकांची यादी क्रमवारी लावण्यासाठी तुम्हाला कोड कुठे आणि का जोडावा लागेल याचा विचार करा.
क्लासिक MVC मॉडेल
MVC घटकांमधील परस्परसंवाद वेब ऍप्लिकेशन्स आणि मोबाईल ऍप्लिकेशन्समध्ये वेगळ्या पद्धतीने लागू केला जातो. याचे कारण असे की वेब अॅप अल्पायुषी आहे, एका वापरकर्त्याच्या विनंतीवर प्रक्रिया करते आणि बाहेर पडते, तर मोबाइल अॅप रीस्टार्ट न करता अनेक विनंत्यांवर प्रक्रिया करते.
वेब ऍप्लिकेशन्स सामान्यत: "निष्क्रिय" मॉडेल वापरतात, तर मोबाईल ऍप्लिकेशन "सक्रिय" मॉडेल वापरतात. सक्रिय मॉडेल, निष्क्रिय मॉडेलच्या विपरीत, आपल्याला सदस्यता घेण्यास आणि त्यातील बदलांच्या सूचना प्राप्त करण्यास अनुमती देते. वेब अनुप्रयोगांसाठी हे आवश्यक नाही.
विविध मॉडेल्समधील घटकांचा परस्परसंवाद यासारखा दिसतो:
मोबाईल ऍप्लिकेशन्स (सक्रिय मॉडेल) सक्रियपणे इव्हेंट आणि इव्हेंट सदस्यता यंत्रणा वापरतात. या दृष्टिकोनासह, दृश्य ( दृश्य ) मॉडेल बदलांचे सदस्यत्व घेते. नंतर, जेव्हा काही घटना घडते (उदाहरणार्थ, वापरकर्ता बटण क्लिक करतो), कंट्रोलरला म्हणतात . हे मॉडेलला डेटा बदलण्याची आज्ञा देखील देते .
जर काही डेटा बदलला असेल, तर मॉडेल हा डेटा बदलण्याबद्दल एक इव्हेंट व्युत्पन्न करते. या इव्हेंटची सदस्यता घेतलेल्या सर्व दृश्यांना (ज्यासाठी हा विशिष्ट डेटा बदलणे महत्त्वाचे आहे) हा कार्यक्रम प्राप्त करतात आणि त्यांच्या इंटरफेसमध्ये डेटा अद्यतनित करतात.
वेब ऍप्लिकेशन्समध्ये, गोष्टी थोड्या वेगळ्या पद्धतीने आयोजित केल्या जातात. मुख्य तांत्रिक फरक असा आहे की क्लायंट सर्व्हरच्या पुढाकारावर सर्व्हर-साइड संदेश प्राप्त करू शकत नाही .
त्यामुळे, वेब अॅप्लिकेशनमधील कंट्रोलर सहसा व्ह्यूवर कोणतेही मेसेज पाठवत नाही, परंतु क्लायंटला एक नवीन पेज देते, जे तांत्रिकदृष्ट्या एक नवीन व्ह्यू किंवा अगदी नवीन क्लायंट अॅप्लिकेशन असते (जर एका पेजला दुसऱ्या पेजबद्दल काहीही माहिती नसेल) .
सध्या, या समस्येचे अंशतः खालील पद्धती वापरून निराकरण केले आहे:
- महत्त्वाच्या डेटामधील बदलांसाठी (मिनिटातून एकदा किंवा त्याहून अधिक) नियमितपणे सर्व्हरचे मतदान करा.
- वेबसॉकेट्स क्लायंटला सर्व्हर संदेशांचे सदस्यत्व घेण्याची परवानगी देतात.
- सर्व्हरच्या बाजूने वेब पुश सूचना.
- HTTP/2 प्रोटोकॉल सर्व्हरला क्लायंटला संदेश पाठवण्यास प्रारंभ करण्यास अनुमती देतो.