क्या निर्भरता इंजेक्शन फ्रेमवर्क एक निर्भरता जोखिम पैदा करते हैं?

Question

मैं निर्भरता इंजेक्शन का उपयोग करने के लिए एक मौजूदा प्रणाली को फिर से तैयार कर रहा हूं, और यह काम आसानी से चल रहा है।

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

मैंने सभी आश्रितों को एक साझा पुस्तकालय पर आश्रित बनाकर उन्हें अलग करने में एक विडंबना देखी।

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

मेरी चिंता यह है कि मैं जिस डीआई फ्रेमवर्क का उपयोग कर रहा हूं वह अप्रचलित हो गया है या उसे बदलने की आवश्यकता है।

क्या DI के साथ काम करते समय एक विकास पैटर्न मौजूद है जो किसी प्रोजेक्ट और DI फ्रेमवर्क के बीच युग्मन को कम करता है?

Comments

"DI फ्रेम का उपयोग न करें" पैटर्न। हालांकि मुझे आश्चर्य होना चाहिए कि क्या आप एक ऐसी समस्या को हल कर रहे हैं जो आपके पास वास्तव में नहीं है - आप डीआई फ्रेमवर्क को बदलने की कितनी संभावना रखते हैं?

— O

@ एक अच्छा DI फ्रेमवर्क पारदर्शी रूप से कोड के साथ काम करने में सक्षम होना चाहिए, लेकिन ऐसे मामले हैं जहां यह संभव नहीं है। फिर आपको अपनी कक्षाओं के अंदर DI एपीआई का उपयोग करना होगा। उन मामलों में, उन वर्गों को बदलने की आवश्यकता के बिना डीआई फ्रेमवर्क को साझा करना या बदलना मुश्किल है। चूंकि यह मेरा पहली बार उस डीआई फ्रेमवर्क के साथ काम कर रहा है। मुझे यकीन नहीं है कि मुझे इसे बदलने की आवश्यकता होगी।

— रिएक्टगुलर

आपका सिस्टम बिजली पर भी निर्भर करता है। मैं आपको सुझाव दूंगा कि पहले

— इदं आर्ये

@MathewFoscarini क्या यह एक विरोधी पैटर्न नहीं है? आप इसे कर सकते हैं, लेकिन आपको यह निर्भरता के अनुसार नहीं करना चाहिए।

— मआर्टिनस

@ मैथ्यू फोसकारिनी DIFramework.Get<IService>()वास्तव में निर्भरता इंजेक्शन नहीं है; यह एक संबंधित पैटर्न है जिसे सर्विस लोकेटर कहा जाता है। बहुत से लोग सेवा लोकेटर को नापसंद करते हैं क्योंकि यह आपको फ्रेमवर्क से जोड़े रखता है और क्योंकि यह बहुत आसानी से दुरुपयोग होता है (जैसे सिंगलटन)। मार्टिन फाउलर का इन पैटर्नों के बारे में एक शानदार लेख है: martinfowler.com/articles/injection.html

— बेंजामिन हॉजसन

Answer 1

आप पूरी तरह से सही हैं - DI फ्रेमवर्क का उपयोग करना संभवतः आपके कोड को उस चीज़ से निर्भर करेगा। वास्तव में, यह बहुत आश्चर्य की बात है, क्योंकि यह आमतौर पर हर दूसरे फ्रेमवर्क या फाउंडेशन लाइब्रेरी के लिए सच है, खासकर जब यह लिब आपके कोड में कहीं भी उपयोग की जाने वाली कुछ सामान्य सुविधाओं के साथ आपकी परियोजना का समर्थन करता है। उदाहरण के लिए, जब आप एक निश्चित UI फ्रेमवर्क या वेब फ्रेमवर्क का उपयोग करने का निर्णय लेते हैं, तो यह निर्णय बाद में बदलना कठिन होता है क्योंकि आपने उस लाइब्रेरी के आधार पर एक निश्चित मात्रा में कोड बनाया है। जब आप एक विशिष्ट (शायद गैर-मानक) Stringवर्ग का उपयोग करने का निर्णय लेते हैं , तो आप उस निर्णय को बाद में आसानी से नहीं बदल सकते। ऐसा निर्णय एक वास्तुशिल्प है, यह एक निश्चित प्रोग्रामिंग भाषा को चुनने जैसा है और कोड के 100K पंक्तियों को लिखे जाने के बाद उस निर्णय को बदलने की कोशिश करें।

आपका सभी कोड एक निश्चित ढांचे पर निर्भर होना एक समस्या नहीं हो सकती है क्योंकि यह तब तक होता है जब तक आप उससे उम्मीद करते हैं, और जब तक यह ठीक से बनाए रखा जाता है। लेकिन अगर यह मामला नहीं है तो यह एक मुद्दा बन सकता है। उस स्थिति से निपटने के लिए कुछ रणनीतियाँ हैं:

• एक विक्रेता से एक रूपरेखा चुनें जिस पर आपको विश्वास है कि वह आपको कई वर्षों से अपडेट और नई रिलीज़ प्रदान कर सकता है

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

• अपनी खुद की रूपरेखा लिखें

• जब तक विक्रेता उपलब्ध है, तब तक स्थिति के साथ रहें और जब वह वास्तव में गायब हो जाए, तो एक अलग फ्रेमवर्क चुनें और एक एडेप्टर बनाने की कोशिश करें जो नए का उपयोग करके पुराने ढांचे का अनुकरण करता है

पहले से एक रैपर लाइब्रेरी बनाने का विचार नया नहीं है, लेकिन मैंने शायद ही कभी उस काम को देखा है, क्योंकि आपको भविष्य की स्थिति के लिए धारणाएं बनानी होंगी, जिसके लिए आपको नहीं पता कि यह आपको कब और कैसे मारा जाएगा, और क्या "नया" ढांचा जैसा दिखेगा। दूसरी ओर, कुछ साल पहले हमने सी + + परियोजना में ~ यूआई कोड के 120K लाइनों के साथ पूरी तरह से यूआई फ्रेमवर्क का आदान-प्रदान किया था।

Answer 2

साधारण कंस्ट्रक्टर इंजेक्शन को एक रूपरेखा की आवश्यकता नहीं होती है। केवल एक चीज जिसे आप खो देते हैं, वह कॉन्फ़िगरेशन फ़ाइल में आपकी निर्भरता को केंद्रीय करने की क्षमता है।

DI कंटेनर एक "एंटरप्राइज़ सॉफ़्टवेयर" पैटर्न है, जिसका उपयोग तब किया जाता है जब ऑब्जेक्ट ग्राफ़ बहुत बड़ा और जटिल होता है। मुझे संदेह है कि 95% अनुप्रयोगों को इसकी आवश्यकता नहीं है।

Comments

मैं सहमत हूं कि छोटी परियोजनाओं को इसकी आवश्यकता नहीं है , लेकिन 95 +% परियोजनाएं इससे लाभान्वित हो सकती हैं।

— मआर्टिनस

@maaartinus: न्यूनतम लाभ के लिए अनावश्यक जोड़ा जटिलता।

— रॉबर्ट हार्वे

क्या? ये प्रति वर्ग मेरे आँकड़े हैं: 0.5 एनोटेशन, 0.1 कॉन्फ़िगरेशन लाइन। तो आपको किस जटिलता का मतलब है ???

— माॅर्टिनस

@RobertHarvey: यद्यपि मैं ऊपर दिए गए आपके कथनों से 100% सहमत हूं, ओपी कहता है कि वह पहले से ही एक डीआई फ्रेमवर्क पेश कर चुका है। उसे "बेहतर मत" बताना वास्तव में उसके प्रश्न का उत्तर नहीं है।

— डॉक ब्राउन

@maaartinus जितना अधिक ढांचा स्वचालित करता है और उतनी ही अधिक जटिल सामग्री को इंजेक्ट कर सकता है। एक्सएमएल कॉन्फिग फाइल, कंस्ट्रक्टर इंजेक्शन, प्रॉपर्टी इंजेक्शन, ऑटोमैटिक ऑब्जेक्ट मॉकिंग, आलसी इंजेक्शन इत्यादि हैं। ये डीआई फ्रेमवर्क बहुत जटिल हो सकते हैं।

— रिएक्टगुलर

Answer 3

मुझे नहीं लगता कि DI चौखटे वास्तव में कभी भी जल्द ही अप्रचलित हो सकते हैं। इसे अप्रचलित बनाने के लिए क्या होना चाहिए?

• एक नया और होशियार पैटर्न का आविष्कार हो सकता है? हालाँकि, यह देखना चाहिए कि, इसे कोड में बहुत बड़े बदलावों की आवश्यकता होगी।
• भाषा में बदलाव शायद? और भी बदतर।

मैं कहूंगा कि वर्तमान DI पर्याप्त परिपक्व है और मुझे वहां होने के बारे में पता नहीं है। आपने अपनी भाषा निर्दिष्ट नहीं की है, इसलिए Guice की बात करें, तो यह काफी गैर-आज्ञाकारी है और मानक जावा एनोटेशन के साथ काम करता है (मानकीकृत नहीं की गई चीजों के लिए अपने स्वयं के उपयोग करता है, लेकिन आपको इसकी आवश्यकता शायद ही हो)। यह खुला खट्टा है, व्यापक रूप से उपयोग किया जाता है, और अपाचे लाइसेंस प्राप्त है। क्या समस्या हो सकती है?

मुझे पूरा यकीन है कि डीआई फ्रेमवर्क को बदलना किसी भी अन्य लाइब्रेरी (जैसे, यूआई परिवर्तन का मतलब बहुत अधिक काम) को बदलने की तुलना में आसान परिमाण का आदेश होगा।