बिल्ट-इन एएसपी.नेट कोर डी कंटेनर पर किसी तीसरे पक्ष डी कंटेनर का उपयोग क्यों करेगा?

Question

वर्तमान में DI विषय - Dependency Injection पर दस्तावेज़ीकरण की कमी है। क्या कोई मुझे निम्नलिखित समझने में मदद कर सकता है:

1. इन पंजीकरणों के बीच क्या अंतर है?

   public void ConfigureServices(IServiceCollection services) 
   { 
       services.AddTransient<IService, Service>(); 
       services.AddScoped<IService, Service>(); 
       services.AddSingleton<IService, Service>(); 
       services.AddInstance(service); 
   } 
   

2. मौजूदा समाधानों (अंतर्निहित, ऑटोफैक, संरचना मानचित्र) जैसे अंतर्निहित डीआई का उपयोग करने के पेशेवर/विपक्ष क्या हैं?
3. डिफ़ॉल्ट निर्भरता इंजेक्शन (यदि कोई है) की वर्तमान सीमाएं क्या हैं?

Answer 1

यहाँ यह समझाया गया है:

• क्षणिक - एक नया उदाहरण हर बार
• scoped बनाई गई है - एक एक उदाहरण वर्तमान क्षेत्र के अंदर बनाई गई है। यह मौजूदा क्षेत्र में सिंगलटन के बराबर है
• सिंगलटन - एक एकल उदाहरण बनाया गया है और यह सिंगलटन
• इंस्टेंस - एक विशिष्ट उदाहरण हर समय दिया जाता है। आप अपने प्रारंभिक निर्माण के लिए जिम्मेदार हैं

अल्फा संस्करण इस सीमाओं था:

• यह केवल निर्माता इंजेक्शन
• का समर्थन करता है यह केवल एक और केवल एक सार्वजनिक निर्माता
• यह नहीं करता है के साथ प्रकार हल कर सकते हैं उन्नत सुविधाओं का समर्थन नहीं करते हैं (जैसे प्रति थ्रेड स्कोप या ऑटो डिस्कवरी)

यदि आप वास्तव में नहीं लिख रहे हैं जटिल उत्पाद डिफ़ॉल्ट डी कंटेनर आपके लिए पर्याप्त होना चाहिए। अन्य मामलों में आप उन पुस्तकालयों को आजमा सकते हैं जिन्हें आपने पहले ही उल्लेख किया है जिनमें उन्नत सुविधाएं हैं।

मेरी सलाह डिफ़ॉल्ट से शुरू करना और कार्यान्वयन बदलना होगा जब (यदि) आप कुछ ऐसा करते हैं जिसे आप इसके साथ नहीं कर सकते हैं।

Answer 2

किसी भी काफी आकार अनुप्रयोग है कि ठोस सिद्धांतों इस प्रकार के उत्पाद विकास के लिए, vNext के अंतर्निहित डि कंटेनर बेकार हो जाएगा, क्योंकि:

• यह आपके विन्यास की पुष्टि करने में मदद नहीं करता है, यह वास्तव में बनाने Captive Dependencies जैसे सामान्य गलत कॉन्फ़िगरेशन से आने वाली समस्याओं का निदान करना मुश्किल है। एक उचित आकार के आवेदन में, इन गलतियों को स्वयं ही खोजना वास्तव में कठिन है।
• इंटरसेप्टर या decorators का उपयोग कर क्रॉस-कटिंग चिंताओं को लागू करना असंभव है। यह किसी भी उचित आकार के आवेदन को वास्तव में महंगी बनाए रखता है।
• यद्यपि यह सामान्य कार्यान्वयन को खोलने के लिए खुले जेनेरिक अबास्ट्रक्शन के मैपिंग का समर्थन करता है, लेकिन यह सामान्य बाधाओं के साथ सामान्य प्रकार के साथ काम करने में असमर्थ है।
• सशर्त पंजीकरण करना असंभव है, इस तरह से पंजीकरण केवल उपभोक्ताओं के एक निश्चित समूह में इंजेक्शन दिया जाता है।

आप एक नया और सरल परियोजना के साथ शुरू करते हैं, तो मेरी सलाह Pure DI लागू करने के लिए (जो एक कंटेनर के उपयोग के बिना हाथ वायर्ड घटक का मतलब है) और your custom IControllerActivator प्लग इन करके अपने प्रकार हल है। बाद में, जब बैच-पंजीकरण और सजावट जैसी सुविधाएं आपके composition root की रखरखाव में सुधार लाती हैं, तो अपनी आवश्यकताओं के अनुरूप स्थापित डी पुस्तकालयों में से एक पर स्विच करें।

Answer 3

इन पंजीकरणों के बीच क्या अंतर है?

• क्षणिक - हर बार यह लिया गया है instantiated
• scoped - http अनुरोध के अनुसार एक बार instantiated और http अनुरोध
• सिंगलटन के जीवन भर के लिए उपलब्ध हो जाएगा - एक बार instantiated और के लिए उपलब्ध हो जाएगा आपके आवेदन
• उदाहरण के पूरे जीवनकाल - बराबर सिंगलटन को छोड़कर आप उदाहरण बनाकर बजाय वस्तु दृष्टान्त प्रदान ढांचे के

स्रोत: http://www.khalidabuhakmeh.com/asp-vnext-dependency-injection-lifecycles, http://dotnetliberty.com/index.php/2015/10/15/asp-net-5-mvc6-dependency-injection-in-6-steps/

Answer 4

अपने पहले सवाल का जवाब करने के लिए: ऐसा लगता है कि ASP.NET docs अपडेट किए गए थे और अब स्पष्ट रूप से उल्लेख क्या के लिए पंजीकरण के प्रत्येक प्रकार है:

ASP.NET सेवाओं के साथ विन्यस्त किया जा सकता निम्नलिखित जीवन काल:

क्षणिक

क्षणिक जीवन सेवाओं जब भी अनुरोध कर रहे हैं बनाई गई हैं ईडी। यह जीवनकाल हल्के, स्टेटलेस सेवा के लिए सबसे अच्छा काम करता है।

Scoped

Scoped जीवन सेवाओं के अनुरोध के अनुसार एक बार बनाई गई हैं।

सिंगलटन

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

उदाहरण [पूर्व आरटीएम केवल!]

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

---

आरटीएम में

नोट अपडेट किया गया कि Asp.Net Core RTM docs में उदाहरण हटा दिया गया था। उदाहरण मूल रूप से सिंगलटन जैसा ही है, लेकिन उनके पास विभिन्न प्रारंभिक अर्थशास्त्र थे (सिंगलटन आलसी लोड था)। लेकिन अब कोई ऐडस्टेंस एपीआई नहीं है, केवल AddSignleton जो पहले से ही बनाया गया उदाहरण ले सकता है।