.NET में DI को लागू करने का "सही" तरीका क्या है?

22

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

जो मैं सोच रहा हूं वह यह है कि मैं कुछ विशिष्ट कारखानों का निर्माण कर सकता हूं जिनमें कुछ विशिष्ट वर्ग प्रकारों के लिए ऑब्जेक्ट बनाने का तर्क होगा। मूल रूप से Ninject Get () विधि का उपयोग करके स्टैटिक क्लास इस क्लास में एक स्टैटिक कर्नेल इंस्टेंस का होता है।

क्या यह मेरे आवेदन में निर्भरता इंजेक्शन को लागू करने का एक सही तरीका होगा या मुझे इसे किसी अन्य सिद्धांत के अनुसार लागू करना चाहिए?

— user3223738
स्रोत

5

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

— पॉल केर्सचर

यह जानना मुश्किल है कि आप किस तरह की .net परियोजना का निर्माण कर रहे हैं। उदाहरण के लिए, MFC के लिए WPF का एक अच्छा उत्तर खराब उत्तर हो सकता है।

— JMK

समाधान के लिए या प्रत्येक परियोजना के लिए एक डीआई मॉड्यूल में सभी निर्भरता पंजीकरणों को व्यवस्थित करने के लिए इसका अच्छा है, और संभवतः कुछ परीक्षणों के लिए आप गहराई से परीक्षण करना चाहते हैं। अरे हाँ, बेशक आपको कंस्ट्रक्टर इंजेक्शन का उपयोग करना चाहिए, अन्य सामान अधिक उन्नत / पागल उपयोगों के लिए है।

— मार्क रोजर्स

30

उस उपकरण के बारे में अभी तक न सोचें जिसका आप उपयोग करने जा रहे हैं। आप एक IoC कंटेनर के बिना DI कर सकते हैं।

पहला बिंदु: मार्क सेमैन की DI .Net में एक बहुत अच्छी किताब है

दूसरा: रचना जड़। सुनिश्चित करें कि पूरा सेट अप प्रोजेक्ट के एंट्री पॉइंट पर किया गया है। आपके बाकी कोड को इंजेक्शन के बारे में पता होना चाहिए, किसी भी उपकरण के बारे में नहीं जिसका उपयोग किया जा रहा है।

तीसरा: कंस्ट्रक्टर इंजेक्शन जाने की सबसे अधिक संभावना है (ऐसे मामले हैं जिनमें आप इसे नहीं चाहते हैं, लेकिन ऐसा नहीं है)।

चौथा: इंजेक्शन के एकमात्र उद्देश्य के लिए अनावश्यक इंटरफेस / कक्षाएं बनाने से बचने के लिए लैम्ब्डा कारखानों और अन्य समान सुविधाओं का उपयोग करना।

— मियामोतो अकीरा
स्रोत

5

सभी उत्कृष्ट सलाह; विशेष रूप से पहला भाग: शुद्ध DI कैसे करना सीखें, और फिर IoC कंटेनरों को देखना शुरू करें जो उस दृष्टिकोण के लिए आवश्यक बॉयलरप्लेट कोड की मात्रा को कम कर सकते हैं।

— डेविड अर्नो

6

... या IoC कंटेनरों को एक साथ छोड़ दें - स्थैतिक सत्यापन के सभी लाभों को रखने के लिए।

— डेन

मुझे यह सलाह पसंद है कि डीआई में आने से पहले यह एक अच्छा शुरुआती बिंदु है, और मेरे पास वास्तव में मार्क सेमन बुक है।

— स्नूप

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

— 15:11 बजे विदित

1

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

— jpmc26

13

आपके प्रश्न के दो भाग हैं - DI को ठीक से कैसे लागू किया जाए, और DI का उपयोग करने के लिए एक बड़े अनुप्रयोग को कैसे रिफलेक्टर किया जाए।

पहले भाग का उत्तर अच्छी तरह से @ मियामोटो अकीरा (विशेषकर मार्क सेमैन के "इननेट नेट इंजेक्शन .net" पुस्तक को पढ़ने के लिए दिया गया है। मार्क्स ब्लॉग भी एक अच्छा मुफ्त संसाधन है।

दूसरा भाग एक अच्छा सौदा अधिक जटिल है।

एक अच्छा पहला कदम यह होगा कि आप क्लास कंस्ट्रक्टर्स में सभी इंस्टेंटेशन को स्थानांतरित करें - निर्भरता को इंजेक्ट न करते हुए, केवल यह सुनिश्चित करें कि आप केवल कॉल करें new कंस्ट्रक्टर में ।

यह आपके द्वारा किए गए सभी एसआरपी उल्लंघनों को उजागर करेगा, जिससे आप छोटे सहयोगियों में कक्षा को तोड़ना शुरू कर सकते हैं।

अगला अंक आपको मिलेगा वर्ग निर्माण के लिए रनटाइम मापदंडों पर निर्भर करते हैं। आप आमतौर पर इसे साधारण कारखानों का निर्माण करके, अक्सर इसके साथ Func<param,type>, निर्माणकर्ता में प्रारंभिक और उन्हें तरीकों से बुलाकर ठीक कर सकते हैं ।

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

यह आपको कुछ इकाई परीक्षण करने की क्षमता देगा, और यदि वह रिफ्लेक्टर का मुख्य लक्ष्य था, तो आप जहां रुक सकते हैं। नया कोड कंस्ट्रक्टर इंजेक्शन के साथ लिखा जाएगा, लेकिन आपका पुराना कोड लिखित रूप में काम करना जारी रख सकता है लेकिन फिर भी परीक्षण योग्य हो सकता है।

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

यह पहले की तरह निपटने के लिए रनटाइम कंस्ट्रक्टर मापदंडों के अधिक मामलों को फेंक देगा।

एक बार यह हो जाने के बाद आप पैरामीटर रहित कंस्ट्रक्टर को हटाना शुरू कर सकते हैं, और शुद्ध DI को रिफैक्टर कर सकते हैं।

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

— स्टीव
स्रोत

3

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

— user3223738

1

खुशी है कि मैं मदद कर सकता हूँ, और हाँ मैं सहमत हूँ कि DI का सबसे बड़ा फायदा ढीली युग्मन है और आसानी से इसे फिर से कॉन्फ़िगर करने की क्षमता है, जिससे यूनिट परीक्षण एक अच्छा दुष्प्रभाव होता है।

— स्टीव

1

पहले मैं यह उल्लेख करना चाहता हूं कि आप एक नई परियोजना शुरू करने के बजाय एक मौजूदा परियोजना को फिर से शुरू करके अपने आप पर यह काफी कठिन बना रहे हैं।

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

डीआई रिफ्लेक्टर के लिए अपने लक्ष्य को बताने का सबसे सरल तरीका यह है कि आप इस घटक से 'नए' ऑपरेटर के सभी उदाहरणों को हटाना चाहते हैं। ये आम तौर पर दो श्रेणियों में आते हैं:

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

आपका आईओसी कंटेनर (निन्यानबे लगता है) उन वस्तुओं को तुरंत हटाने और आपके कारखाने के इंटरफेस को लागू करने की जिम्मेदारी लेगा। जो कुछ भी आपके द्वारा संशोधित किए गए घटक का उपयोग कर रहा है, उसे IoC कंटेनर के बारे में जानना होगा ताकि यह आपके घटक को पुनः प्राप्त कर सके।

एक बार जब आप उपरोक्त पूरा कर लेते हैं, तो आप अपने चयनित घटक में DI से जो भी लाभ प्राप्त करने की उम्मीद कर रहे हैं, उसे पुनः प्राप्त कर सकेंगे। अब उन यूनिट परीक्षणों को जोड़ने / तय करने का एक अच्छा समय होगा। यदि मौजूदा यूनिट परीक्षण थे, तो आपको इस बारे में निर्णय लेना होगा कि क्या आप वास्तविक वस्तुओं को इंजेक्ट करके उन्हें एक साथ पैच करना चाहते हैं या लंड का उपयोग करके नए यूनिट टेस्ट लिख सकते हैं।

'बस' अपने आवेदन के प्रत्येक घटक के लिए उपरोक्त दोहराएं, आईओसी कंटेनर के संदर्भ को ऊपर ले जाते हुए जब तक आप केवल तब तक चले जब तक कि इसके बारे में जानने के लिए केवल मुख्य आवश्यकता न हो।

— जॉन
स्रोत

1

अच्छी सलाह: 'बिग री-राइट' के बजाय एक छोटे से घटक के साथ शुरू करें

— डैनियल हॉलिनरेके

0

सही दृष्टिकोण निर्माण इंजेक्शन का उपयोग करने के लिए है, यदि आप उपयोग करते हैं

जो मैं सोच रहा हूं वह यह है कि मैं कुछ विशिष्ट कारखानों का निर्माण कर सकता हूं जिनमें कुछ विशिष्ट वर्ग प्रकारों के लिए ऑब्जेक्ट बनाने का तर्क होगा। मूल रूप से Ninject Get () विधि का उपयोग करके स्टैटिक क्लास इस क्लास में एक स्टैटिक कर्नेल इंस्टेंस का होता है।

फिर आप निर्भरता इंजेक्शन की तुलना में, सेवा लोकेटर के साथ समाप्त होते हैं।

— लो फ्लाइंग पेलिकन
स्रोत

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

— user3223738

2

नहीं, जब आप डीआई कंटेनर को इनिशियलाइज़ करते हैं, तो आपको इंटरफेस के कार्यान्वयन को निर्दिष्ट करना होगा, और डीआई कंटेनर इंस्टेंट को बनाएगा और कंस्ट्रक्टर को इंजेक्ट करेगा।

— लो फ्लाइंग पेलिकन

व्यक्तिगत रूप से, मुझे लगता है कि कंस्ट्रक्टर इंजेक्शन का अत्यधिक उपयोग किया जा सकता है। मैंने इसे बहुत बार देखा है कि 10 अलग-अलग सेवाओं को इंजेक्ट किया जाता है और केवल एक फ़ंक्शन कॉल के लिए वास्तव में आवश्यक होता है - फ़ंक्शन का वह हिस्सा तब क्यों नहीं होता है?

— शहरीहुस्की

2

यदि 10 अलग-अलग सेवाओं को इंजेक्ट किया जाता है, तो ऐसा इसलिए है क्योंकि कोई एसआरपी का उल्लंघन कर रहा है, जिसे छोटे घटकों में विभाजित किया जाना चाहिए।

— लो फ्लाइंग पेलिकन

1

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

— वू

0

आप कहते हैं कि आप इसका उपयोग करना चाहते हैं, लेकिन ऐसा क्यों करें।

DI, इंटरफेस से कॉन्सेप्ट पैदा करने के लिए एक तंत्र प्रदान करने के अलावा और कुछ नहीं है।

यह अपने आप में डीआईपी से आता है । यदि आपका कोड पहले से ही इस शैली में लिखा गया है और आपके पास एक ही स्थान है, जहां पर सहमति बनती है, तो DI पार्टी के लिए अधिक कुछ नहीं लाता है। यहाँ DI फ्रेमवर्क कोड जोड़ना बस बाहर ब्लोट और अपने कोड आधार obfuscate होगा।

मान लेते हैं आप इसका उपयोग चाहते हैं, आप आमतौर पर कारखाने / बिल्डर / कंटेनर (या जो भी) को आवेदन में जल्दी सेट करते हैं, तो यह स्पष्ट रूप से दिखाई देता है।

NB यह बहुत आसान है कि आप अपना खुद का रोल करें जो आपको Ninject / StructureMap या जो कुछ भी करने की बजाय चाहिए। यदि आपके पास कर्मचारियों का एक उचित टर्नओवर है, तो यह पहिए को एक मान्यता प्राप्त ढांचे का उपयोग करने के लिए या कम से कम इसे उस शैली में लिख सकता है ताकि यह सीखने की अवस्था से बहुत अधिक न हो।

— रोबी डी
स्रोत

0

वास्तव में, "सही" तरीका एक कारखाने का उपयोग तब तक नहीं करना है जब तक कि कोई अन्य विकल्प न हो (जैसा कि इकाई परीक्षण और कुछ नकली - उत्पादन कोड के लिए आप कारखाने का उपयोग नहीं करते हैं)! ऐसा करना वास्तव में एक प्रतिमान है और इसे हर कीमत पर टाला जाना चाहिए। DI कंटेनर के पीछे का पूरा बिंदु गैजेट को आपके लिए काम करने की अनुमति देता है ।

जैसा कि एक पूर्व पोस्ट में ऊपर कहा गया था, आप चाहते हैं कि आपका आईओसी गैजेट आपके ऐप में विभिन्न आश्रित वस्तुओं के निर्माण के लिए जिम्मेदारी ग्रहण करे। इसका मतलब है कि अपने DI गैजेट को विभिन्न उदाहरणों को स्वयं बनाने और प्रबंधित करने दें। DI के पीछे यह पूरा बिंदु है - आपकी वस्तुओं को पता होना चाहिए कि वे उन वस्तुओं को कैसे बनाते और / या प्रबंधित करते हैं जिन पर वे निर्भर हैं। अन्यथा करने के लिए ढीली युग्मन को तोड़ता है।

एक मौजूदा एप्लिकेशन को सभी DI में बदलना एक बहुत बड़ा कदम है, लेकिन ऐसा करने में स्पष्ट कठिनाइयों को अलग करते हुए, आप यह भी चाहेंगे कि (DI जीवन को थोड़ा आसान बनाने के लिए) DI टूल का पता लगाने के लिए जो आपके बाइंडिंग के थोक को स्वचालित रूप से प्रदर्शित करेगा। (निनॉज़ जैसी चीज़ का मूल वह "kernel.Bind<someInterface>().To<someConcreteClass>()"कॉल है जो आप अपने इंटरफ़ेस घोषणाओं को उन ठोस वर्गों से मेल खाने के लिए बनाते हैं जिन्हें आप उन इंटरफेस को लागू करने के लिए उपयोग करना चाहते हैं। यह "बिंद" कॉल हैं जो आपके DI गैजेट को आपके कंस्ट्रक्टर कॉल को इंटरसेप्ट करने और प्रदान करने की अनुमति देते हैं। आवश्यक निर्भर वस्तु उदाहरण। कुछ वर्ग के लिए एक विशिष्ट कंस्ट्रक्टर (छद्म कोड यहां दिखाया गया है) हो सकता है:

public class SomeClass
{
  private ISomeClassA _ClassA;
  private ISomeOtherClassB _ClassB;

  public SomeClass(ISomeClassA aInstanceOfA, ISomeOtherClassB aInstanceOfB)
  {
    if (aInstanceOfA == null)
      throw new NullArgumentException();
    if (aInstanceOfB == null)
      throw new NullArgumentException();
    _ClassA = aInstanceOfA;
    _ClassB = aInstanceOfB;
  }

  public void DoSomething()
  {
    _ClassA.PerformSomeAction();
    _ClassB.PerformSomeOtherActionUsingTheInstanceOfClassA(_ClassA);
  }
}

ध्यान दें कि कहीं नहीं उस कोड में भी कोई कोड नहीं बनाया गया था जो /ConcreteClassA या SomeOtherConcreteClassB के उदाहरण को बनाया / प्रबंधित / जारी किया था। वास्तव में, न तो ठोस वर्ग को संदर्भित किया गया था। तो ... जादू कहाँ हुआ?

आपके ऐप के स्टार्ट अप हिस्से में, निम्नलिखित हुआ (फिर से, यह छद्म कोड है लेकिन यह वास्तविक (Ninject) चीज़ के बहुत करीब है ...):

public void StartUp()
{
  kernel.Bind<ISomeClassA>().To<SomeConcreteClassA>();
  kernel.Bind<ISomeOtherClassB>().To<SomeOtherConcreteClassB>();
}

कोड का वह छोटा सा हिस्सा निनॉज़ गैजेट को कंस्ट्रक्टरों की तलाश करने, उन्हें स्कैन करने, उन इंटरफेस के उदाहरणों को देखने के लिए कहता है जिन्हें इसे संभालने के लिए कॉन्फ़िगर किया गया है (जो कि "बाइंड" कॉल है) और फिर कंक्रीट क्लास का एक उदाहरण बनाएं और स्थानापन्न करें उदाहरण संदर्भित है।

एक अच्छा उपकरण है जो Ninject को बहुत अच्छी तरह से Ninject.Extensions.Conventions (अभी तक एक और NuGet पैकेज) कहा जाता है जो आपके लिए इस काम का थोक काम करेगा। सीखने के उत्कृष्ट अनुभव से दूर नहीं जाने के रूप में आप इसे स्वयं बना लेंगे, लेकिन स्वयं को आरंभ करने के लिए, यह जांच का एक उपकरण हो सकता है।

यदि स्मृति कार्य करती है, तो यूनिटी (औपचारिक रूप से Microsoft अब एक ओपन सोर्स प्रोजेक्ट है) के पास एक विधि कॉल या दो है जो समान कार्य करते हैं, अन्य उपकरणों में समान सहायक होते हैं।

आप जो भी रास्ता चुनते हैं, निश्चित रूप से अपने डि ट्रेनिंग के थोक के लिए मार्क सीमन की पुस्तक पढ़ें, हालांकि, यह ध्यान दिया जाना चाहिए कि सॉफ्टवेयर इंजीनियरिंग की दुनिया के "ग्रेट ओन्स" (जैसे मार्क) भी गलतियां कर सकते हैं - मार्क सभी के बारे में भूल गए अपनी पुस्तक में Ninject इसलिए यहाँ केवल Ninject के लिए लिखा गया एक और संसाधन है। मेरे पास यह है और इसका एक अच्छा पढ़ा: डिपेंडेंसी इंजेक्शन के लिए मास्टेरिंग निनजेक्ट

— फ्रेड
स्रोत

0

कोई "सही तरीका" नहीं है, लेकिन पालन करने के लिए कुछ सरल सिद्धांत हैं:

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

बस इतना ही। सुनिश्चित करने के लिए, कि सिद्धांत कानून नहीं हैं, लेकिन यदि आप उनका पालन करते हैं, तो आप यह सुनिश्चित कर सकते हैं कि आप DI करते हैं (कृपया मुझे सही करें अगर मैं गलत हूं)।

तो, "नया" के बिना और डीआई कंटेनर को जाने बिना रनटाइम के दौरान ऑब्जेक्ट कैसे बनाएं?

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

— JanDotNet
स्रोत