सीएमएस जूमला की विकास योजनाओं का अध्ययन, मेरे
पिछले लेखों (यूक्रेनी) में से एक को लिखने के लिए, मैं संक्षिप्त नाम HMVC में आया। यह समझना मुश्किल नहीं था कि यह किसी तरह मानक एमवीसी पैटर्न से जुड़ा था। प्रतिलेख में पाया गया: "HMVC - पदानुक्रमित मॉडल-दृश्य-नियंत्रक" - थोड़ा समझाया गया। जानकारी के लिए आगे की खोजों में भी अधिक उपज नहीं हुई, मुख्य रूप से पैटर्न के बारे में सैद्धांतिक चर्चा और व्यवहार में इसका उपयोग करने के बारे में लगभग कुछ भी नहीं। हालांकि, थोड़ा प्रतिबिंब के बाद, मुझे एहसास हुआ कि मैंने पहले ही सिम्फनी 2 पर अपनी पिछली परियोजना में इसका इस्तेमाल किया था। इसके अलावा, यह पता चला है कि कई लोग आंशिक रूप से इस पैटर्न का उपयोग करते हुए भी इसे साकार किए बिना।
एमवीसी जारी करता है
सिद्धांत रूप से परिपूर्ण, MVC अभ्यास में कई चुनौतियों का सामना करता है। शुरू करने के लिए, आइए याद करें कि मुख्य समस्या को क्या हल करना चाहिए: आवेदन को उनके बीच न्यूनतम निर्भरता प्राप्त करने के लिए तीन अलग-अलग पहलुओं (नियंत्रक, दृश्य और मॉडल) में विभाजित करना, साथ ही साथ आवेदन के विभिन्न हिस्सों के बीच। पाठ्यपुस्तकों के उदाहरणों में, यह सब ठीक है। कुछ का एक मॉडल है, डेटा प्रदर्शित करने के लिए एक दृश्य और उपयोगकर्ता कार्यों के जवाब में कार्रवाई करने के लिए एक नियंत्रक है।
समस्या एक
व्यवहार में, आपको आमतौर पर एक ही समय में कई मॉडल संचालित करने होते हैं, उदाहरण के लिए: लेख, उपयोगकर्ता, टिप्पणियां। सिद्धांत रूप में, यह महत्वपूर्ण नहीं है, एमवीसी पैटर्न इसके लिए प्रदान करता है, लेकिन यह निर्भरता की संख्या बढ़ाता है - दृश्य और नियंत्रक एक से अधिक मॉडल पर निर्भर करते हैं, और एक से अधिक दृश्य और नियंत्रक एक मॉडल पर निर्भर करते हैं।
दूसरी समस्या
विभिन्न मॉडलों से डेटा प्रदर्शित करने के लिए, मैं विशेष रूप से उनके लिए बनाए गए विचारों का उपयोग करना चाहूंगा। उदाहरण के लिए, टिप्पणियों को लेखों और उत्पादों के लिए उसी तरह प्रदर्शित करना तर्कसंगत लगता है। यह क्लासिक MVC प्रदान नहीं करता है, लेकिन यह आंशिक रूप से टेम्प्लेट के उपयोग से बाईपास होता है। यानी एक दृश्य का उपयोग किया जाता है जो मॉडल से डेटा प्राप्त करता है, और उनके प्रदर्शन को प्रदर्शित करने के लिए कई टेम्पलेट्स के संयोजन का उपयोग किया जाता है। और फिर से निर्भरता की संख्या बढ़ जाती है।
समस्या तीन
कभी-कभी कार्रवाई एक मॉडल पर नहीं, बल्कि एक ही समय में कई पर करने की आवश्यकता होती है। उदाहरण के लिए, उपयोगकर्ता को हटाते समय, आपको उसके सभी लेखों और टिप्पणियों को हटाना होगा। नतीजतन, आपको एक नियंत्रक बनाना होगा जो न केवल उस मॉडल पर संचालन का वर्णन करता है जिससे वह संबंधित है (उदाहरण में, उपयोगकर्ता), लेकिन उन मॉडलों पर जिनसे वह सीधे संबंधित नहीं है। इस प्रकार, गैर-स्पष्ट निर्भरताएं दिखाई देती हैं।
HMVC का मूल विचार
इन समस्याओं को कैसे ठीक करें? चूंकि समस्याएँ इस तथ्य के कारण उत्पन्न होती हैं कि MVC के बजाय यह MMMVVVCC की तरह कुछ निकलता है, जहाँ प्रत्येक मॉडल प्रकार और नियंत्रक अलग-अलग उप-प्रणालियों से संबंधित हो सकते हैं, तो उत्तर स्पष्ट है - MVC पर वापस लौटें जिसमें केवल एक मॉडल, प्रकार और नियंत्रक है।
इसलिए, HMVC का पहला सिद्धांत: एप्लिकेशन केवल कठोर रूप से तय किए गए मॉडल-व्यू-कंट्रोलर ट्रायड्स का उपयोग करता है जो विशेष रूप से कंट्रोलर के माध्यम से बाकी सबसिस्टम के साथ बातचीत करते हैं।
इससे एक दूसरा सिद्धांत निकलता है: अधिक जटिल संयोजनों को व्यवस्थित करने के लिए त्रिकोणीय पदानुक्रम का उपयोग किया जाता है।
पहली नज़र में, ऐसा लग सकता है कि HMVC को लागू करने में सक्षम होने के लिए, किसी अन्य नियंत्रक से नियंत्रक को कॉल करने की क्षमता पर्याप्त है। लेकिन एक वेब अनुप्रयोग में, व्यवहार न केवल नियंत्रक को दिए गए आदेश पर निर्भर करता है, बल्कि संपूर्ण रूप से http अनुरोध पर भी निर्भर करता है। मॉडल और दृश्य दोनों ही अनुरोध का विश्लेषण कर सकते हैं और किसी तरह से अपने व्यवहार को बदल सकते हैं। इसलिए, अनुरोध को किसी अन्य नियंत्रक को स्थानांतरित करने की क्षमता की आवश्यकता है, और जरूरी नहीं कि प्राप्त के समान ही हो। आप इसे तीन अलग-अलग तरीकों से कर सकते हैं।
HMVC क्लाइंट सर्वर
Http अनुरोध भेजने का सबसे आसान तरीका इसके लिए एक ब्राउज़र का उपयोग करना है। इस मामले में, इसे फ्रेमवर्क द्वारा किसी विशेष समर्थन की आवश्यकता भी नहीं है। और इस दृष्टिकोण का उपयोग हर जगह किया जाता है - जिसे AJAX कहा जाता है। हां, वह अजाक्स है। हम पेज की मुख्य सामग्री (उदाहरण के लिए, लेख का पाठ) को प्रदर्शित करने के लिए एक बुनियादी ट्रायड मॉडल-व्यू-कंट्रोलर का उपयोग कर सकते हैं, जो कि एक ही ट्रायड के लिए अजाक्स-अनुरोधों का उपयोग करके शेष आवश्यक टुकड़े (उदाहरण के लिए, टिप्पणियां) प्राप्त करेगा।
यह दृष्टिकोण आपको पृष्ठ के कुछ हिस्सों (ब्राउज़र में कैश डेटा, प्रॉक्सी सर्वर या प्रॉक्सी http-सर्वर) के लिए http-caching का उपयोग करने और वास्तविक समय मोड में भाग डाउनलोड करने की अनुमति देता है। उदाहरण के लिए, एक लेख पृष्ठ को कुछ हिस्सों में लोड किया जा सकता है:
- लेख के पाठ के साथ पृष्ठ ही स्थिर है और, यदि संभव हो तो, ब्राउज़र कैश से हटा दिया जाता है, जिसे लंबे समय तक संग्रहीत किया जा सकता है;
- टिप्पणियां लगातार अपडेट की जाती हैं और इसलिए उन्हें कैश नहीं किया जाता है और वेब सर्वर से हर बार अनुरोध किया जाता है;
- नवीनतम समाचार ब्लॉक को समय-समय पर अपडेट किया जाता है, इसे कैश से पुनर्प्राप्त किया जा सकता है, लेकिन यह तब तक संग्रहीत नहीं किया जाता है जब तक कि यह लेख न हो।
पेशेवरों:
- ढांचे के लिए कोई समर्थन की आवश्यकता नहीं है (आप इसके बिना कर सकते हैं);
- लचीला http कैशिंग
- एक अन्य वेब सर्वर को अनुरोध भेजने की क्षमता, इस प्रकार कई सर्वरों के बीच लोड का वितरण।
विपक्ष:
- जावा स्क्रिप्ट लिखने की जरूरत है;
- ब्राउज़र से सर्वर तक अनुरोधों की संख्या बढ़ जाती है, जो पृष्ठ लोड समय और वेब सर्वर पर लोड बढ़ा सकता है।
सर्वर से सर्वर HMVC
अगले सबसे आसान कार्यान्वयन वेब सर्वर द्वारा स्वयं को अनुरोध भेजना है। इसके लिए, कर्ल का उपयोग किया जा सकता है, या HTTP अनुरोध भेजने में सक्षम एक अन्य पुस्तकालय। यह दृष्टिकोण पिछले एक के समान है, लेकिन इस अंतर के साथ कि अनुरोध उपयोगकर्ता के ब्राउज़र द्वारा नहीं भेजे जाते हैं, लेकिन दस्तावेज़ को बनाने की प्रक्रिया में वेब सर्वर द्वारा ही।
एक उदाहरण के रूप में, टिप्पणी पर फिर से विचार करें। पृष्ठ एक लेख पर आधारित है, इसलिए, इसे प्रदर्शित करने के लिए लेख के नियंत्रक, दृश्य और मॉडल का उपयोग किया जाता है। लेकिन अगर क्लासिक एमवीसी मॉडल और टिप्पणी प्रकार का उपयोग लेख दृश्य के अंदर टिप्पणी प्रदर्शित करने के लिए करता है, तो एचटीएमवी टिप्पणी नियंत्रक के लिए अनुरोध भेजने का प्रावधान करता है। इस मामले में, एक HTTP अनुरोध के माध्यम से जो एक समानांतर प्रक्रिया के शुभारंभ की शुरुआत करता है, जो लेख के लिए टिप्पणियों का तैयार ब्लॉक तैयार करेगा।
जैसा कि पिछले मामले में, इस दृष्टिकोण के साथ http-caching का उपयोग करना संभव है, लेकिन इसका उपयोग करने के लिए आपको प्रॉक्सी http-सर्वर का उपयोग करना होगा, उदाहरण के लिए nginx।
पेशेवरों:
- क्लाइंट को एक समाप्त पृष्ठ दिया गया है;
- लचीला http कैशिंग
- एक अन्य वेब सर्वर को अनुरोध भेजने की क्षमता, इस प्रकार कई सर्वरों के बीच लोड का वितरण।
विपक्ष:
- एक पृष्ठ बनाने के लिए, कई समानांतर प्रक्रियाएं शुरू की जाती हैं, जो वेब सर्वर पर लोड बढ़ाती हैं।
इंट्रा-सर्वर HMVC
शब्द "इंट्रा-सर्वर" से मेरा मतलब है कि सब कुछ वेब अनुप्रयोग प्रक्रिया के अंदर होता है। जैसा कि पिछले मामले में, मॉडल-व्यू-कंट्रोलर ट्रायड्स अनुरोधों के माध्यम से एक-दूसरे के साथ संवाद करते हैं, और उन्हें उसी तरह से माना जाना चाहिए जैसे नियमित http अनुरोध, हालांकि, इन अनुरोधों का हस्तांतरण रूपरेखा प्रदान करता है। प्रोग्रामर के दृष्टिकोण से, पिछले दो विकल्प महत्वपूर्ण रूप से भिन्न नहीं हैं। एक अच्छी रूपरेखा में, अंतर केवल एक पैरामीटर में होना चाहिए, जो इंगित करता है कि क्या उपकुंजी आंतरिक होना चाहिए (प्रक्रिया के भीतर), या बाहरी (वास्तविक http अनुरोध का कारण)।
पेशेवरों:
- समानांतर में वेब एप्लिकेशन का एक उदाहरण चलाने की कोई आवश्यकता नहीं है।
विपक्ष:
- http कैशिंग का उपयोग करने का कोई तरीका नहीं है।
एक HMVC आवेदन स्केलिंग
यदि कोई वेब संसाधन काफी लोकप्रिय हो जाता है, तो सवाल उठ सकता है कि एक सर्वर इसके लिए पर्याप्त नहीं है। और फिर सवाल कई सर्वरों के बीच लोड संतुलन का होता है। लोड को जल्दी से वितरित करने का सबसे आसान विकल्प संसाधन और डेटाबेस प्रतिकृति की कई प्रतियों का उपयोग करना है। लेकिन एचएमवीसी आपको दूसरे तरीके से जाने की अनुमति देता है - सर्वर के बीच कार्यों को वितरित करना। उदाहरण के लिए, एक सर्वर लेख, एक उपयोगकर्ता प्रोफाइल और एक तीसरी टिप्पणी का प्रबंधन करता है। मॉड्यूल के पर्याप्त अलगाव के मामले में, इसके त्वरित कार्यान्वयन के लिए, यह उपयुक्त अनुरोधों में पंजीकृत करने के लिए पर्याप्त है कि वे बाहरी हैं और उनके प्रसंस्करण के लिए सर्वर के पते का संकेत देते हैं।
अंत में
एक वास्तविक वेब एप्लिकेशन बनाने के लिए HMVC कार्यान्वयन विकल्पों में से किसी एक तक सीमित नहीं होना चाहिए। प्रत्येक मामले में, आप वह चुन सकते हैं जो उसके लिए सबसे उपयुक्त हो। और विकल्प "सर्वर-सर्वर" और "इंट्रा-सर्वर" को सामान्य रूप से "चलते-फिरते" पर स्विच किया जा सकता है।