DI का उपयोग कैसे शुरू करें

मुझे बार-बार यह विचार आया कि DI कुछ जटिल, भारी, धीमा है, केवल "बड़ी" परियोजनाओं के लिए उपयुक्त है, और इसलिए विशेष रूप से वर्तमान कार्य (500+ मॉडल वर्ग, 300+ नियंत्रक वर्ग) पर इसका उपयोग अनुचित है। यह आंशिक रूप से इस तथ्य के कारण है कि डीआई स्पष्ट रूप से सिम्फनी के "द डिपेंडेंसी इंजेक्शन घटक" जैसे पैकेजों से जुड़ा हुआ है, जो स्पष्ट रूप से सभी संभावित निर्भरता इंजेक्शन विकल्पों से अधिक को कवर करता है।
यहां मैं एक निश्चित कार्यात्मक न्यूनतम देना चाहता हूं, जो कि अवधारणा की एक समझ प्रदान करेगा, यह दिखाने के लिए कि निर्भरता का व्युत्क्रम स्वयं काफी सरल और संक्षिप्त हो सकता है।

सामग्री

कार्यान्वयन कोड की 500 लाइनों की 2 कक्षाएं हैं:
SimpleDi \ ClassManager - कक्षाओं के बारे में जानकारी प्रदान करता है। पूर्ण कार्य के लिए, इसे कैश की आवश्यकता होती है (हम Doctrine \ Common \ Cache \ ApcCache का उपयोग करते हैं), यह हमें स्क्रिप्ट के लिए हर कॉल के साथ प्रतिबिंब नहीं बनाने की अनुमति देगा। बाद के इंजेक्शन के लिए पर्स का एनोटेशन। यह बूटलोडर में भी इस्तेमाल किया जा सकता है, जैसा कि यह क्लास फ़ाइल के लिए पथ संग्रहीत करता है।
SimpleDi \ ServiceLocator - इससे बनाई गई सेवाओं को बनाता है और आरंभ करता है। यह वह वर्ग है जो इंजेक्शन बनाता है।
1) सरलतम स्थिति में, जब वर्ग के लिए कोई सेटिंग निर्दिष्ट नहीं की जाती है, तो SimpleDi \ ServiceLocator मल्टीटन पैटर्न (उर्फ ऑब्जेक्ट पूल) के समान कार्य करता है।

$service_locator->get('HelperTime'); 

2) क्षेत्र के माध्यम से कार्यान्वयन विकल्प

 class A { /** * @Inject("HelperTime") * @var HelperTime */ protected $helper_time; } $service_locator->get('A'); 

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

• किसी भी दृश्यता (संरक्षित, निजी सहित) वाले क्षेत्रों के लिए नियंत्रकों में और यह प्रदर्शन पर थोड़े प्रभाव के कारण होता है, और इसके अलावा, नियंत्रक स्वयं एक सेवा कंटेनर है (और हमारे ServiceLocator :: get () के समान विधि है)
  
• सार्वजनिक क्षेत्रों के लिए किसी भी वर्ग (सेवाओं) में, जैसा कि इस स्थिति में कोई प्रतिबिंब नहीं बनाया जाएगा, और $ सेवा का एक सरल असाइनमेंट-> फ़ील्ड = $ इंजेक्ट_ सर्विस का उपयोग किया जाएगा, जो निजी / संरक्षित क्षेत्रों के लिए अपवाद का कारण बनेगा।
  

हमारे कार्यान्वयन में, प्रतिबिंब हमेशा बनाया जाता है, कार्यान्वयन हमेशा सफलतापूर्वक समाप्त होगा।
3) विधि के माध्यम से कार्यान्वयन

 class B { /** * @var HelperTime */ protected $helper_time; /** * @Inject("HelperTime") * @param HelperTime $helper */ public function setHelperTime($helper) { $this->helper_time = $helper; } } $service_locator->get('B'); 

यह विकल्प सबसे स्वीकार्य है और, फ़ील्ड के माध्यम से कार्यान्वयन के साथ, डिफ़ॉल्ट रूप से निर्भरता निर्धारित करने के लिए उपयोग किया जाना चाहिए।
4) विन्यास के माध्यम से तैनाती

 $service_locator->setConfigs(array( 'class_b_service' => array( 'class' => 'B', 'calls' => array( array('setHelperTime', array('@CustomHelperTime')), ) ) )); $service_locator->get('class_b_service'); 

यह निर्भरता इंजेक्शन के लिए प्रयोग किया जाता है। अब सेटिंग्स के माध्यम से कक्षा बी में उपयोग किए जाने वाले सहायक को बदलना संभव है, जबकि वर्ग बी खुद नहीं बदलेगा।
5) कक्षा का एक नया उदाहरण बनाएं। जब आपको एक ही वर्ग के कई ऑब्जेक्ट्स की आवश्यकता होती है, तो आप ServiceLocator को एक कारखाने के रूप में उपयोग कर सकते हैं

 $users_factory = $service_locator; $users_row = array( array('id' => 1, 'name' => 'admin'), array('id' => 2, 'name' => 'guest'), ); $users = array(); foreach ($users_rows as $row) { $user = $users_factory->createService('User'); $user->setData($row); } 

उदाहरण

एक मनमाना उपयोगी पुस्तकालय लें और इसे हमारी परियोजना में लागू करने का प्रयास करें। मान लीजिए कि यह github.com/yiisoft/yii/blob/master/framework/utils/CPasswordHelper.php है
यह पता चला है कि हम ऐसा नहीं कर सकते, क्योंकि वर्ग पूरी तरह से अनावश्यक वर्गों Yii और CException से बंधा हुआ है।

 class CPasswordHelper { … public static function generateSalt($cost=13) { if(!is_numeric($cost)) throw new CException(Yii::t('yii','{class}::$cost must be a number.',array('{class}'=>__CLASS__))); $cost=(int)$cost; if($cost<4 || $cost>31) throw new CException(Yii::t('yii','{class}::$cost must be between 4 and 31.',array('{class}'=>__CLASS__))); if(($random=Yii::app()->getSecurityManager()->generateRandomString(22,true))===false) if(($random=Yii::app()->getSecurityManager()->generateRandomString(22,false))===false) throw new CException(Yii::t('yii','Unable to generate random string.')); return sprintf('$2a$%02d$',$cost).strtr($random,array('_'=>'.','~'=>'/')); } } 

किसी भी परियोजना के लिए कक्षा को उपलब्ध कराने के लिए, यह निर्भरता का सही वर्णन करने के लिए पर्याप्त होगा:

 class CPasswordHelper { /** *      public ,        , *    . * @Inject * @var \Yii\SecurityManager */ public $securityManager; /** *   * @Inject * @var \YiiExceptor */ public $exceptor; … public function generateSalt($cost=13) { if(!is_numeric($cost)) $this->exceptor->create('yii','{class}::$cost must be a number.',array('{class}'=>__CLASS__)); $cost=(int)$cost; if($cost<4 || $cost>31) $this->exceptor->create('yii','{class}::$cost must be between 4 and 31.',array('{class}'=>__CLASS__)); if(($random=$this->securityManager->generateRandomString(22,true))===false) if(($random=$this->securityManager()->generateRandomString(22,false))===false) this->exceptor->create('yii','Unable to generate random string.'); return sprintf('$2a$%02d$',$cost).strtr($random,array('_'=>'.','~'=>'/')); } } 

और एक वर्ग प्राप्त करें - एक अपवाद जनरेटर

 class YiiExceptor { public function create($a, $b, $c = null) { throw new CException(Yii:t($a, $b, $c)); } } 

निष्कर्ष

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

संदर्भ

Github.com/mthps/SimpleDi स्वयं उदाहरण है
थ्योरी en.wikipedia.org/wiki/D dependency_Injection
Symfony.com/doc/current/compenders/d dependency_injection/index.html के सर्वोत्तम कार्यान्वयनों में से एक