🙅 👩🏿‍🤝‍👩🏽 👩🏿‍💼 HMVC के साथ स्केल वेब एप्लिकेशन 👩🏾‍✈️ 🔌 🧜🏽

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

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

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

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

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

पदानुक्रमित-मॉडल-दृश्य-नियंत्रक पैटर्न

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

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

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

कोहना 3 अन्य नियंत्रकों को कॉल करने के लिए अंतर्निहित अनुरोध ऑब्जेक्ट का उपयोग करता है। अनुरोध दोनों आंतरिक हो सकते हैं - आवेदन नियंत्रकों के लिए, और बाहरी - वेब सेवाओं के लिए। दोनों ही मामलों में, एक ही अनुरोध वर्ग का उपयोग किया जाता है। यदि MVC ट्रायड को दूसरे सर्वर में ले जाया जाता है, तो केवल एक पैरामीटर को बदलना होगा।

<?php class Controller_Default extends Controller { public function action_index() { //    $internal_request = Request::factory('controller/action/param') ->execute(); //    $external_request = Request::factory('http://www.ibuildings.com/controller/action/param') ->execute(); } }

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

आंतरिक नियंत्रकों के डेटा को पुनः प्राप्त करने के लिए कोहना में अनुरोध वर्ग का उपयोग करना आपको अन्य फ्रेमवर्क जैसे कि Zend फ्रेमवर्क में पुनर्निर्देशित कार्यों की याद दिला सकता है। वास्तव में, ये दो बिल्कुल अलग विधियां हैं। कोहना में अनुरोधित वस्तुएँ अद्वितीय अनुरोधों के रूप में अलगाव में काम कर सकती हैं, और जब क्रियाओं को पुनर्निर्देशित किया जाता है, तो उनमें से प्रत्येक निर्मित अनुरोध के अंदर मौजूद होता है। नीचे यह प्रदर्शित करने के लिए एक उदाहरण है।

डिफ़ॉल्ट नियंत्रक - /application/controllers/default.php

 <?php //     class Controller_Default extends Controller { public function action_index() { //     GET if ($this->request->method === 'GET') { //  POST,  array (0) { empty } var_dump($_POST); //       $log = Request::factory('/log/access/'.$page_id); //  POST     $log->method = 'POST'; //  -    $log->post = array( 'uid' => $this->user->id, 'ua' => Request::user_agent('browser'), 'protocol' => Request::$protocol, ); //   $log->execute(); //  POST,   array (0) { empty } var_dump($_POST); } } }

लॉग कंट्रोलर - /application/controllers/log.php

 <?php //     class Controller_Log extends Controller { public function action_access($page_id) { //     index ( ) //       // array(3){string (3) 'uid' => int (1) 1, string (2) 'ua' => string(10) 'Mozilla... var_dump($_POST); //    Log $log = new Log_Model; //     $log->set_values($_POST) ->save(); } }

उपरोक्त उदाहरण अनुरोध ऑब्जेक्ट के लिए उपलब्ध स्वतंत्रता को दर्शाता है। प्रारंभ में, GET अनुरोध डिफ़ॉल्ट नियंत्रक की अनुक्रमणिका क्रिया को आमंत्रित करता है, जिसके जवाब में लॉग नियंत्रक की पहुँच क्रिया के लिए POST अनुरोध बनाया जाता है। सूचकांक क्रिया तीन वैरिएबल को मान प्रदान करती है जो पहले नियंत्रक से वैश्विक $_POST

सरणी के लिए सुलभ नहीं हैं। जब दूसरा अनुरोध निष्पादित किया जाता है, तो $_POST

पहले से ही चर होते हैं जो हमने इसे उपलब्ध कराया है। ध्यान दें कि इंडेक्स कंट्रोलर में $log->execute()

पूरा होने के बाद, $_POST

का डेटा गायब हो जाता है। अन्य रूपरेखाओं में, इस इंटरैक्शन के कार्यान्वयन के लिए, उदाहरण के लिए, कर्ल का उपयोग करके एक नई क्वेरी बनाने की आवश्यकता है।

गाज़ोलाइमेंट, माइक्रोब्लॉगिंग सेवा

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

सबसे पहले, यातायात अपेक्षाकृत छोटा होगा, क्योंकि सेवा नई है और लोगों को अभी भी इसके बारे में नहीं पता है। इसलिए, कुछ भी बुरा नहीं होगा यदि अब के लिए सभी एप्लिकेशन लॉजिक को एक सर्वर पर निष्पादित किया जाएगा।

उपयोगकर्ता के होम पेज को प्रदर्शित करने के लिए एक नियंत्रक लिखें। इसकी नवीनतम स्थितियां और लोगों की एक सूची होगी जिसका उपयोगकर्ता ने अनुसरण किया है।

इंडेक्स कंट्रोलर - /application/controllers/index.php

 <?php //    http://gazouillement.com/samsoir/ class Controller_Index extends Controller { public function action_index() { //   (samsoir)   $user = new Model_User($this->request->param('user')); //    ,   404 if ( ! $user->loaded) throw new Controller_Exception_404('Unable to load user :user', array(':user' => $this->request->param('user'))); //      xhtml $messages = Request::factory('messages/find/'.$user->name.'.xhtml') ->execute() ->response; //      xhtml $relations = Request::factory($user->name.'/following.xhtml') ->execute() ->response; //        //     ,    $this->request->response = View::factory('user/home', array( 'user' => $user, 'messages' => $messages, 'relations' => $relations, )); } }

अब देखते हैं कि Controller_Index::action_index()

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

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

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

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

रूट सेटअप - /application/bootstrap.php

 Route::set('messages', 'messages/<action>/<user>(<format>)', array('format' => '\.\w+')) ->defaults(array( 'format' => '.json', 'controller' => 'messages', ));

यह संदेश सेवा के लिए एक मार्ग बनाता है, जो अब तक मुख्य एप्लिकेशन के डोमेन के अंदर है। पता संदेशों / खोज / samsoir.xhtml के माध्यम से एक अनुरोध संदेश नियंत्रक पर पुनर्निर्देशित किया जाएगा, जो find()

कार्रवाई के पैरामीटर 'user' => 'samsoir'

और 'format => '.json'

के रूप में पारित किया जाएगा।

संदेश नियंत्रक - /application/controllers/messages.php

 <?php class Controller_Messages extends Controller { //  ,    protected $supported_formats = array( '.xhtml', '.json', '.xml', '.rss', ); //      protected $user; //      //       public function before() { //        if ( ! in_array($this->request->param('format'), $this->supported_formats)) throw new Controller_Exception_404('File not found'); //     $this->user = new Model_User($this->request->param('user')); if ( ! $this->user->loaded()) throw new Controller_Exception_404('File not found'); return parent::before(); } //      public function find() { //         1:M $messages = $this->user->messages; //    ,   prepare    $this->request->response = $this->_prepare_response($messages); } //      protected function _prepare_response(Model_Iterator $messages) { //  ,      switch ($this->request->param('format') { case '.json' : { $this->request->headers['Content-Type'] = 'application/json'; $messages = $messages->as_array(); return json_encode($messages); } case '.xhtml' : { return View::factory('messages/xhtml', $messages); } default : { throw new Controller_Exception_404('File not found!'); } } } }

उपयोगकर्ता संदेशों को विस्तार से प्राप्त करने की प्रक्रिया नियंत्रक Controller_Messages

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

निर्दिष्ट ऑब्जेक्ट को लागू करने before()

अनुरोध ऑब्जेक्ट हमेशा before()

विधि को कॉल करता है। यह आपको मुख्य कार्य से पहले विभिन्न नियमित संचालन करने की अनुमति देता है। before()

विधि पहले समर्थन के लिए अनुरोधित प्रारूप की जांच करती है, और फिर शुद्धता के लिए उपयोगकर्ता नाम। यदि अपवादों को फेंकने before()

समाप्त होता है, तो अनुरोध ऑब्जेक्ट find()

कार्रवाई को कॉल करेगा। यह उपयोगकर्ता संदेशों को एक Model_Iterator ऑब्जेक्ट के रूप में लोड करता है। यह ध्यान दिया जाना चाहिए कि उपयोगकर्ता के संबंध में कोई संदेश नहीं मिलने पर इट्रेटर खाली हो जाएगा। यह संदेश _prepare_response()

को _prepare_response()

विधि से पास करने के साथ समाप्त होता है, जो आउटपुट के डेटा को सही ढंग से प्रारूपित करता है और सभी आवश्यक हेडर सेट करता है।

कंट्रोलर Controller_Index

और Controller_Messages

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

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

स्टीफन फ्राई प्रभाव

स्टीफन फ्राई ( @stephenfry ) सबसे प्रसिद्ध ट्विटर उपयोगकर्ताओं में से एक है जिसके 2 मिलियन से अधिक अनुयायी हैं। वह अपने माइक्रोब्लॉग में URL प्रकाशित करके साइटों को निष्क्रिय करने में सक्षम है, जिससे सर्वर पर DDOS हमला होता है।

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

पहले बड़ी मात्रा में यातायात होगा। प्रति सेकंड कई सौ अनुरोधों के बजाय, आवेदन को हजारों की प्रक्रिया करनी होगी। इस परिदृश्य में, Gazouillement सर्वर पर भीड़ और संभवतः "पुट" का अनुभव करना शुरू कर देगा। यह स्पष्ट हो जाएगा कि स्पष्ट रूप से बढ़ते ट्रैफ़िक से निपटने के लिए एप्लिकेशन को कुछ अनुकूलन और सुधार की आवश्यकता है।

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

आप बूटलोडर में केवल एक पैरामीटर बदलकर Profiler को सक्षम कर सकते हैं।

लोडर - /application/bootstrap.php

 //-- Environment setup -------------------------------------------------------- Kohana::$profiling = TRUE;

अंत में, नियंत्रक प्रतिक्रिया के अंत में एक Profiler दृश्य जोड़ें। यह after()

विधि के माध्यम से सबसे अच्छा किया जाता है, फिर सभी कार्यों के लिए प्रोफाइलर को दिखाया जाएगा।

इंडेक्स कंट्रोलर - /application/controllers/index.php

 public function after() { //       $this->request->response .= View::factory('profiler/stats'); }

प्रोफाइलर को चालू करने के बाद, इसकी जानकारी इस नियंत्रक से प्रत्येक क्रिया के निचले भाग में दिखाई देने लगती है। एक वर्ग बनाना सबसे अच्छा है जो नियंत्रक को विरासत में मिला है और इस वर्ग के after()

विधि में प्रोफाइलर दृश्य सम्मिलित करें। अब सभी सिस्टम कंट्रोलर विकास के दौरान प्रोफाइलर डिबगिंग जानकारी प्रदर्शित करते हैं।

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

गजौलिमेंट को स्केल करना

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

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

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

संदेश सेवा को किसी अन्य सर्वर पर ले जाया गया और डेटाबेस के साथ काम करने के लिए अनुकूलित किया गया। यह नया सर्वर केवल मैसेजिंग से संबंधित कार्य करता है, इस प्रकार ऐसे सभी ऑपरेशनों की गति को काफी बढ़ाता है।

इंडेक्स कंट्रोलर - /application/controllers/index.php

 <?php //    http://gazouillement.com/samsoir/ class Controller_Index extends Controller { protected $_messages_uri = 'http://messages.gazouillement.com'; public function action_index() { //   (samsoir)   $user = new Model_User($this->request->param('user')); //    ,   404 if ( ! $user->loaded) throw new Controller_Exception_404('Unable to load user :user', array(':user' => $this->request->param('user'))); // --    -- //  URI     $messages_uri = $this->_messages_uri.'/find/'.$user->name'.xhtml'; //       xhtml $messages = Request::factory($messages_uri) ->execute() ->response; // --    -- //      xhtml $relations = Request::factory($user->name.'/following.xhtml') ->execute() ->response; //        //     ,    $this->request->response = View::factory('user/home', array( 'user' => $user, 'messages' => $messages, 'relations' => $relations, )); } }

कोड नियंत्रक Controller_Index::action_index()

में एक छोटे से बदलाव पर प्रकाश डाला गया है Controller_Index::action_index()

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

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

आप Kohana के बारे में और जानकारी फ्रेमवर्क वेबसाइट पर प्राप्त कर सकते हैं, और Kohana PHP 3 फाइल को Github से डाउनलोड किया जा सकता है। अभी भी एपीआई दस्तावेज है: http://v3.kohanaphp.com/guide ।

इस उदाहरण में उपयोग की जाने वाली क्वेरी क्लास वर्तमान में मेरे व्यक्तिगत गितुब खाते - http://github.com/samsoir/core पर कोहना कर्नेल विकास शाखा में उपलब्ध है। यदि आप आधिकारिक कोहाना PHP 3.0 वितरण का उपयोग कर रहे हैं, तो आपको प्रश्नों के लिए एक संशोधित वर्ग विस्तार की आवश्यकता है।

HMVC के साथ स्केल वेब एप्लिकेशन

पदानुक्रमित-मॉडल-दृश्य-नियंत्रक पैटर्न

गाज़ोलाइमेंट, माइक्रोब्लॉगिंग सेवा

स्टीफन फ्राई प्रभाव

गजौलिमेंट को स्केल करना

More articles: