मैंने
PHPixie ढांचे और उस पर प्रोग्रामिंग के बारे में कई बार लिखा है। इस बार हम अंदर देखते हैं और अनुप्रयोग जीवन चक्र को देखते हैं, सौभाग्य से कोड की सादगी और रैखिकता हमें सापेक्ष आसानी से ऐसा करने की अनुमति देती है।
सिम्फनी की तरह, PHPixie में दो भाग होते हैं: एक घटक पुस्तकालय और एक आधार परियोजना, हालांकि PHPixie के मामले में, आधार परियोजना पतली है और इसमें केवल कुछ फाइलें शामिल हैं। यहां वह एक उदाहरण की भूमिका निभाता है, और इसलिए, इसे खुद के लिए बदलना न केवल स्वागत योग्य है, बल्कि कुछ मामलों में आवश्यक भी है। यह इसके लिए है कि यह समझना महत्वपूर्ण है कि सिस्टम में क्या हो रहा है और कैसे। अपने कुछ सीमित ड्राइंग कौशल का उपयोग करके, मैंने एक क्वेरी प्रोसेसिंग आरेख तैयार किया
बेशक, उन लोगों के लिए जो पहले से ही एमवीसी (या इस मामले में भी वीसी से परिचित हैं, क्योंकि मैंने एक मॉडल नहीं बनाया है), यह योजना संभवतः परिचित प्रतीत होगी, लेकिन शुरुआती लोगों के लिए यह बहुत उपयोगी हो सकता है। तो, हम index.php से शुरू करते हैं, जहाँ सभी प्रश्न आते हैं, यहाँ सबसे महत्वपूर्ण लाइनें हैं:
$pixie = new \App\Pixie(); $pixie->bootstrap($root)->handle_http_request();
और एकदम से हम सबसे महत्वपूर्ण हिस्से में पहुंच जाते हैं, App \ Pixie वर्ग जो फ्रेम का दिल है, उसका DI कंटेनर। इसके माध्यम से, आप अन्य सभी घटकों तक पहुंच सकते हैं। App \ Pixie PHPixie- कोर पुस्तकालय से PHPixie \ Pixie से विरासत में मिला है। आधार परियोजना डेवलपर को इसे परिवर्तन करने का अवसर प्रदान करने के लिए सीधे PHPixie \ पिक्सी का उपयोग करने के बजाय इस वर्ग की घोषणा करती है (उदाहरण के लिए, एक मॉड्यूल में प्लग)।
यह इस बात पर ध्यान देने योग्य है कि आप इस कंटेनर में नई इकाइयाँ नहीं जोड़ सकते हैं, जैसे कि Silex में, आपको कक्षा में सब कुछ स्पष्ट रूप से वर्णित करना होगा। हालांकि यह पहली नज़र में इतना सुविधाजनक नहीं लग सकता है, यह आपको बेहतर कोड पठनीयता प्राप्त करने की अनुमति देता है, पूरी तरह से सभी संस्थाओं (क्योंकि वे सभी वर्ग गुण बन जाते हैं) को दस्तावेज करते हैं, और आईडीई में इन संस्थाओं पर सुझाव भी प्राप्त करते हैं। चूंकि PHPixie \ Pixie में सभी फैक्टरिंग विधियां भी होती हैं, इसलिए यह हमें संबंधित पद्धति को ओवरलोड करके आसानी से फ्रेमवर्क के किसी भी वर्ग को बदलने की अनुमति देगा।
बूटस्ट्रैप () विधि $ पिक्सी को आरंभ करती है, विन्यास पढ़ती है, अपवाद से निपटने में सक्षम बनाती है, आदि। बस
handle_http_request () अनुरोध पर कार्रवाई की जा रही है। इस प्रक्रिया में तीन चरण होते हैं:
- $ PHP क्लास के अनुरोध के $ अनुरोध वस्तु बनाना
- यह ऑब्जेक्ट उपयुक्त नियंत्रक को दिया जाता है और इसी क्रिया को निष्पादित किया जाता है।
- निष्पादन के दौरान, नियंत्रक $ प्रतिक्रिया वस्तु (PHPixie \ प्रतिक्रिया) को संशोधित करता है
- $ प्रतिसाद (हेडर और सामग्री) से डेटा उपयोगकर्ता को भेजा जाता है
सभी तीन सबसे महत्वपूर्ण वस्तुएं $ अनुरोध, $ प्रतिक्रिया और $ पिक्सी PHPixie \ नियंत्रक वर्ग की विशेषताओं के रूप में उपलब्ध हैं। अब PHPixie कोड लिखने के लिए कुछ और प्रतिमानों पर थोड़ा जोर दें:
फैक्टरिंग विधियों को छोड़कर कहीं भी "नए" ऑपरेटर का उपयोग न करें। प्रत्येक नए वर्ग के पास अपने उदाहरण बनाने के लिए एक भाज्य विधि होनी चाहिए (उदाहरण के लिए, App \ Pixie में)। यह दृष्टिकोण एक वर्ग को दूसरे के साथ प्रतिस्थापित करना आसान बनाता है, जो विशेष रूप से इकाई परीक्षण लिखते समय महत्वपूर्ण है। इसलिए उदाहरण के लिए एक नियंत्रक का परीक्षण, अब आप इसे एक लॉक किया गया App \ Pixie पास कर सकते हैं, जो वास्तविक कक्षाओं के बजाय, उनके मोकी को संचारित करेगा।
स्थिर गुणों और विधियों का उपयोग न करें। स्टैटिक्स का उपयोग करना परीक्षणों के लेखन को बहुत जटिल करता है। PHPixie का उपयोग करके आप उनके बिना आसानी से कर सकते हैं, बस एक उदाहरण को App \ Pixie की विशेषता के रूप में जोड़ें और आप इसे लगभग कहीं से भी एक्सेस कर सकते हैं। तो हम वास्तव में एक सिंगलटन प्राप्त करते हैं। वैसे, आप इसे $ inst_classes में जोड़कर कर सकते हैं।
namespace App; class Pixie extends \PHPixie\Pixie { public function __construct() { $this->instance_classes['singleton'] = '\App\Singleton'; } }
मॉड्यूल कैसे काम करते हैं?
PHPixie के लिए प्रत्येक मॉड्यूल एक अतिरिक्त क्लास लाइब्रेरी है जो अपने DI कंटेनर को मुख्य PHPixe \ Pixie के समान प्रदान करता है, अर्थात, इसमें क्लास इंस्टेंसेस बनाने के लिए फ़ैक्टरी विधियाँ शामिल हैं जो मॉड्यूल में शामिल हैं। फिर हम इसे मुख्य कंटेनर में मॉड्यूल के सरणी में जोड़ते हैं:
namespace App; class Pixie extends \PHPixie\Pixie { protected $modules = array( 'db' => '\PHPixie\DB', 'orm' => '\PHPixie\ORM' ); }
लेकिन क्या होगा अगर मैं उदाहरण के लिए अपने ऐप \ मॉडल के साथ PHPixie \ ORM \ मॉडल वर्ग को बदलना चाहता हूं? यह आसान है, आपको अभी भी अपना खुद का App \ ORM (PHPixie \ ORM का विस्तार) प्राप्त करने की आवश्यकता है () विधि, जो PHPixie \ ORM \ मॉडल के बजाय, हमें जो चाहिए वह वापस कर देगा। इसमें, फ्रेमवर्क के विचारों में से एक स्वयं अधिक प्रकट होता है - मानक ओओपी तकनीकों का उपयोग करने के लिए किसी तरह के जादू के बजाय जितना संभव हो सके। उदाहरण के लिए, फ्रेमवर्क के वर्ग को बदलने के लिए, आपको सबक्लास_प्रिफ़िक्स का उपयोग करना होगा और इसे कॉन्फ़िगरेशन स्तर पर करना होगा न कि वास्तविक प्रोग्रामिंग को। यह दृष्टिकोण आपको सिस्टम की अपनी समझ में सुधार करने की अनुमति देता है, क्योंकि अधिकांश भाग के लिए आप फ्रेमवर्क के बारे में कुछ भी जानने के बिना फ़ाइल का पता लगा सकते हैं, केवल कक्षाओं को देखकर।
लेकिन हुक, घटनाओं और अधिक के बारे में क्या?
वे नहीं हैं और जैसा कि मैं समझता हूं कि यह नहीं होगा। ऐसी चीजें पूरी तरह से एक अलग प्रतिमान से होती हैं क्योंकि वे कोड को गैर-रैखिक बनाते हैं, विशेष रूप से घटनाओं के संबंध में, जहां यह हमेशा पूरी तरह से स्पष्ट नहीं होता है कि कौन सा श्रोता पहले शुरू होगा और क्या होगा अगर वह किसी प्रकार की घटना को बुलाता है। इसके अलावा, बैकट्रैक्स की पठनीयता अक्सर उनके उपयोग से ग्रस्त होती है, क्योंकि उन्हें स्वयं फ्रेमवर्क द्वारा कहीं न कहीं कहा जाता है, जहां प्रोग्रामर ने खुद को सुनिश्चित करने के लिए कोड नहीं लिखा था। यदि आपको किसी जगह पर कुछ करने की ज़रूरत है, तो यह उस विधि को ओवरलोड करना बहुत आसान है जो बस ऐसा करता है और आपको इसके लिए तर्क की आवश्यकता है।
अगले लेख में, मैं या तो अधिक विस्तार से जांच करूंगा कि PHPixie डेटाबेस के साथ कैसे काम करता है, या अधिक मोटे तौर पर रैखिक बनाम घटना संचालित प्रोग्रामिंग के पेशेवरों और विपक्षों का वर्णन करता है।