निर्भरता इंजेक्शन को भाषा में कैसे एकीकृत किया जा सकता है? [बन्द है]


10

मैं थोड़ा सोच रहा हूं कि कैसे निर्भरता इंजेक्शन को सीधे भाषा की तरह सी # में एकीकृत किया जा सकता है। मैं एक संभावित समाधान के साथ आया हूं, जिस पर मैं आपकी राय सुनना चाहता हूं। मैंने कई निर्भरता इंजेक्शन फ्रेमवर्क का उपयोग नहीं किया है इसलिए कुछ ऐसा हो सकता है जो मैं देख रहा हूं

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

इसी प्रकार आप उस सेवा के लिए विभिन्न प्रकार के हैंडलर पंजीकृत करते हैं ताकि आप इंजेक्ट किए गए संपत्ति प्रकार को तुरंत कर सकें।

इस तरह के आर्किटेक्चर IMO का उपयोग करने का उल्टा तरीका यह है कि यह काफी लचीला और उपयोग में आसान है। नकारात्मक पक्ष यह है कि हर बार जब आप इंजेक्शन लगाने वाले वर्ग को आरंभ करते हैं, तो एकल को कॉलआउट करने के कुछ ओवरहेड हो सकते हैं।

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

सोचा, मुद्दे, सवाल, बेहतर विचार?

कोड

public class SomeClass
{

  public SomeClass()
  {
     //implicit behavior if Animal is not set in constructor or initializer
    this.Animal =  GlobalInjector.Get(this,typeof(Mammal))

  }

  public injectable Mammal Animal  
  {
   get;
   set;
  }
}


 GlobalInjector.Register(typeof(Mammal), () => return new Mammal(someParameter));

क्या आप उन लोगों के लिए एक छद्म कोड उदाहरण दे सकते हैं जो DI से परिचित नहीं हैं? पुनश्च। हो सकता है कि आप DI के संबंध में मेरे प्रश्न का उत्तर दे सकें? :)
स्टीवन

2
मुझे यकीन नहीं है कि मुझे मिल जाएगा। आप एक वैश्विक DI कंटेनर और एक कीवर्ड के बजाय '[Injectable]' विशेषता के साथ वह सब प्राप्त कर सकते हैं, है ना?
निकी

नमस्ते, मैंने आपके प्रश्न पर DI के बारे में थोड़ा लिखने की कोशिश की, यह सुनिश्चित नहीं है कि यह इसका उत्तर देता है
होमडे

nikie: हाँ यकीन है, मुझे लगता है कि आप विभिन्न तरीकों से वास्तविक तंत्र को लागू कर सकते हैं, अगर अंतर्निहित तर्क ध्वनि है तो मुझे अधिक दिलचस्पी है
होमड

तो इस और मौजूदा IoC के बीच आपके अतिरिक्त कीवर्ड के अलावा क्या अलग है?
मैथ्यू Whited

जवाबों:


7

ऐसी चीजें हैं जो भाषाओं में हैं, और ऐसी चीजें जो नहीं हैं। बहुत पहले C ने माना कि IO भाषा में नहीं था क्योंकि यह कंप्यूटिंग मॉडल के लिए बाहरी है और इसे फंक्शन लाइब्रेरी के साथ लागू किया जा सकता है।

डिपेंडेंसी इंजेक्शन ऐसा है। यह भाषा के लिए बाहरी है और इसे उचित रूपरेखा के साथ लागू किया जा सकता है।

आधुनिक भाषाओं के साथ एक समस्या यह है कि वे बहुत अधिक करने की कोशिश करते हैं। अंततः वे भाषाएं अपने स्वयं के वजन के तहत ढह जाती हैं क्योंकि प्रोग्रामर सरल भाषाओं में भाग जाते हैं।


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

5

इसकी जरूरत नहीं है

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

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

इस तरह के एक डिजाइन के साथ आपको निर्भरता इंजेक्शन का समर्थन करने के लिए भाषा को बदलने की आवश्यकता नहीं है।

यह संभावित खतरनाक है

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

कुछ मायनों में यह एक कोने में खुद को चित्रित कर सकता है:

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

4

क्या आपने .NET 4 के साथ आने वाले प्रबंधित एक्सटेंसीबिलिटी फ्रेमवर्क को देखा है ? यहाँ एक लेख मैंने कुछ उदाहरणों के साथ लिखा है। मूल रूप से यह .NET में निर्मित निर्भरता इंजेक्शन का एक रूप है, रन-टाइम खोज की अतिरिक्त सुविधाओं के साथ।

संपत्ति के इंजेक्शन इस तरह दिखते हैं:

class Program
{
    [Import]
    public IMessageSender MessageSender { get; set; }
}

कंस्ट्रक्टर इंजेक्शन इस तरह दिखते हैं:

class Program
{
    [ImportingConstructor]
    public Program(IMessageSender messageSender) 
    {
    ...
    }
}

आप फ़ील्ड आयात कर सकते हैं, वैकल्पिक आयात कर सकते हैं, मेटाडेटा के साथ आयात करने सहित आलसी सेवाओं का आयात कर सकते हैं ताकि आप तुरंत सेवा के लिए एक उपयुक्त सेवा की खोज कर सकें। आप नए एक्सटेंशन देखने के लिए रनटाइम पर फिर से आयात कर सकते हैं।


जबकि MEF वास्तव में प्लगइन सामान के लिए अच्छा है, मुझे नहीं लगता कि मैं इसे एक सामान्य DI तंत्र के रूप में उपयोग करना चाहता हूं
Homde

1
@MKO - क्या आप इसे याद कर रहे हैं पर विस्तार से बता सकते हैं? मैं उन सभी लेखों से अवगत हूँ जहाँ ग्लेन ब्लॉक लोगों को आश्वस्त करने के लिए दौड़ता है कि MEF सभी DI फ्रेमवर्क को बदलने के लिए बाहर नहीं है, लेकिन यदि आप विवरणों को देखते हैं, तो यह स्पष्ट है कि किसी भी अन्य की तुलना में राजनीतिक वक्तव्य अधिक है। हालाँकि, यदि आप अन्य DI फ्रेमवर्क की तुलना में MEF के अभाव वाले फीचर्स की एक अच्छी सूची दे सकते हैं, जो लोगों को एक सूचित निर्णय लेने में मदद करेगा। इसके अलावा, प्रश्न C # में DI फ्रेमवर्क के बारे में है, और MEF .NET फ्रेमवर्क में स्पष्ट रूप से DI कंटेनर है।
स्कॉट व्हिटलॉक

2
  1. आप वास्तव में विन्यास तंत्र का वर्णन नहीं करते हैं, जो IMHO मुश्किल सा है। आप एक धागे में चलने वाले सभी कोड DB-कनेक्शन A, दूसरे धागे कनेक्शन B में सभी कोड का उपयोग कैसे करते हैं? आप एक निश्चित संसाधन के इंजेक्शन को कैसे रोक सकते हैं, क्योंकि वर्तमान में लॉग इन किया गया उपयोगकर्ता इसे एक्सेस करने की अनुमति नहीं देता है?
  2. एक वैश्विक इंजेक्टर का उपयोग न करें। किसी भी वैश्विक चीज का उपयोग न करें, या आप वैश्विक चर का उपयोग कर सकते हैं। नहीं, वैश्विक के बजाय OOP- स्पीक जैसे सिंगलटन या "स्टैटिक" का उपयोग करने से उनके वैश्विक स्वरूप में बदलाव नहीं होता है।
  3. एक गतिशील रूप से स्कोप्ड कंटेनर पर विचार करें। जबकि लेक्सिकल स्कूपिंग ने गतिशील स्कूपिंग के खिलाफ सही जीत हासिल की है, मेरा मानना ​​है कि डायनेमिक स्कोप वैश्विक स्कोप के लिए एक अच्छा प्रतिस्थापन बना देगा। विभेदक वंशानुक्रम एक अच्छा कार्यान्वयन होगा (जैसे प्रोटोटाइप आधारित विरासत में)।
  4. मेरा मानना ​​है कि एक भाषा-अनिवार्य डीआई-तंत्र वास्तव में सरल होना चाहिए, उस एन्ट्रीप्रिसिए सामान में से कोई भी सी # और जावा में आदर्श नहीं है। शीर्ष पर एक साधारण विन्यास परत के साथ एक गतिशील स्कूपिंग तंत्र चाल कर सकता है। Enterprisey समाधान शीर्ष पर तीसरे पक्ष द्वारा स्तरित किया जा सकता है।
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.