कोणीय 6+ पूर्ण निर्भरता इंजेक्शन गाइड है। प्रोवाइडर्स बनाम प्रदाता: []

कोणीय 6 ने एक अनुप्रयोग ( प्रदान ) में सेवा निर्भरता को एम्बेड करने के लिए एक नया बेहतर सिंटैक्स पेश किया। इस तथ्य के बावजूद कि कोणीय 7 पहले ही जारी किया जा चुका है, यह विषय अभी भी प्रासंगिक है। GitHub, Slack और Stack Overflow की टिप्पणियों में बहुत भ्रम है, तो आइए इस विषय पर करीब से नज़र डालें।

इस लेख में हम विचार करेंगे:

1. निर्भरता इंजेक्शन
2. निर्भरता को एंगुलर ( प्रदाताओं: [] ) में इंजेक्ट करने का पुराना तरीका;
3. कोणीय में निर्भरता को इंजेक्ट करने का एक नया तरीका ( बशर्ते: 'रूट' | SomeModule );
4. परिदृश्य में प्रदान करता है ;
5. अनुप्रयोगों में नए सिंटैक्स का उपयोग करने के लिए सिफारिशें;
6. संक्षेप में देना।

निर्भरता इंजेक्शन

यदि आप पहले से ही DI के बारे में विचार रखते हैं, तो आप इस अनुभाग को छोड़ सकते हैं।

निर्भरता इंजेक्शन ( DI ) उन वस्तुओं को बनाने का एक तरीका है जो अन्य वस्तुओं पर निर्भर करते हैं। निर्भरता इंजेक्शन प्रणाली आश्रित वस्तुओं को प्रदान करती है जब यह एक वर्ग को तत्काल करती है।

- कोणीय प्रलेखन

औपचारिक स्पष्टीकरण अच्छे हैं, लेकिन आइए निर्भरता इंजेक्शन क्या है पर करीब से नज़र डालें।

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

मान लीजिए हमारी सेवाओं में से एक में निम्नलिखित कोड है:

constructor(private http: HttpClient) 

यदि आप निर्भरता इंजेक्शन तंत्र का उपयोग किए बिना इसे बनाते हैं, तो आपको मैन्युअल रूप से HttpClient जोड़ना होगा। फिर कोड इस तरह दिखेगा:

 const myService = new MyService(httpClient) 

लेकिन इस मामले में httpClient पाने के लिए कहाँ ? इसे भी बनाने की आवश्यकता है:

 const httpClient = new HttpClient(httpHandler) 

लेकिन अब httpHandler कहां से लाएं ? और इसी तरह, जब तक कि सभी आवश्यक कक्षाएं तत्काल न हों। जैसा कि हम देख सकते हैं, मैनुअल निर्माण जटिल हो सकता है और प्रक्रिया में त्रुटियां हो सकती हैं।

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

कोणीय में निर्भरता को इंजेक्ट करने का पुराना तरीका (प्रदाता: [])

आवेदन को चलाने के लिए, कोणीय को प्रत्येक व्यक्तिगत वस्तु के बारे में जानना होगा जिसे हम घटकों और सेवाओं में लागू करना चाहते हैं। एंगुलर 6 जारी होने से पहले, ऐसा करने का एकमात्र तरीका प्रदाताओं को संपत्ति में सेवाएं निर्दिष्ट करना था : [] सज्जाकार @NgModule , @Component और @Directive ।



यहाँ प्रदाताओं के तीन मुख्य उपयोग हैं : [] :

1. तुरंत लोड किए गए मॉड्यूल ( उत्सुक ) के @NgModule डेकोरेटर में;
2. देरी लोडिंग मॉड्यूल ( आलसी ) के @NgModule डेकोरेटर में;
3. सज्जाकारों में @Component और @ अप्रत्यक्ष ।

आवेदन के साथ डाउनलोड किए गए मॉड्यूल (ईगर)

इस मामले में, सेवा वैश्विक दायरे में सिंगलटन के रूप में पंजीकृत है। कई मॉड्यूल के प्रदाताओं [] में शामिल होने पर भी यह एक सिंगलटन होगा। सेवा वर्ग का एक एकल उदाहरण बनाया गया है जो आवेदन के मूल स्तर पर पंजीकृत होगा।

आस्थगित लोड मॉड्यूल (आलसी)

आलसी मॉड्यूल से जुड़ी सेवा का एक उदाहरण इसके आरंभ के दौरान बनाया जाएगा। मॉड्यूल के उत्सुक घटक के लिए इस तरह की सेवा को जोड़ने से त्रुटि उत्पन्न होगी: MyService के लिए कोई प्रदाता नहीं! त्रुटि ।

@ घटक और @ निर्देश में कार्यान्वयन

जब एक घटक या निर्देश में लागू किया जाता है, तो सेवा का एक अलग उदाहरण बनाया जाता है, जो इस घटक और सभी बच्चों में उपलब्ध होगा। इस स्थिति में, सेवा एक सिंगलटन नहीं होगी, इसका उदाहरण हर बार घटक का उपयोग किया जाता है और डोम से घटक को हटाने के साथ-साथ हटा दिया जाता है।



इस मामले में, RandomService को मॉड्यूल स्तर पर लागू नहीं किया जाता है और यह एक सिंगलटन नहीं है,
लेकिन प्रदाताओं के साथ पंजीकृत : [] रैंडम कॉमपोनेंट घटक का। परिणामस्वरूप, हमें <randm> </ randm> का उपयोग करते समय हर बार एक नया यादृच्छिक नंबर मिलेगा।

कोणीय में निर्भरता को इंजेक्ट करने का नया तरीका (बशर्ते: 'रूट' | SomeModule)

कोणीय 6 में, हमें एक आवेदन में निर्भरता को इंजेक्ट करने के लिए एक नया "ट्री-शेकेबल प्रोवाइडर्स" टूल मिला है, जिसका उपयोग @ इनजेक्टेबल डेकोरेटर की संपत्ति में किया जा सकता है।

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

सेवा को एप्लिकेशन के मूल में प्रदान किया जा सकता है ( प्रदान किया गया: 'रूट' ) या किसी भी मॉड्यूल में ( प्रदान किया गया: SomeModule )। प्रदान की गई: 'रूट' AppModule में कार्यान्वयन के लिए एक संक्षिप्त नाम है।



आइए नए सिंटैक्स का उपयोग करने के लिए मुख्य परिदृश्यों का विश्लेषण करें:

1. आवेदन के मूल मॉड्यूल में कार्यान्वयन ( प्रदान किया गया: 'रूट' );
2. तुरंत लोड किए गए मॉड्यूल ( उत्सुक ) में कार्यान्वयन;
3. विलंबित लोडिंग ( आलसी ) के साथ मॉड्यूल में कार्यान्वयन।

आवेदन के मूल मॉड्यूल में कार्यान्वयन (प्रदान किया गया: 'रूट')

यह सबसे आम निर्भरता इंजेक्शन विकल्प है। इस मामले में, सेवा को केवल बंडल एप्लिकेशन में जोड़ा जाएगा यदि यह वास्तव में उपयोग किया जाता है, अर्थात। एक घटक या अन्य सेवा में एम्बेडेड।

नए दृष्टिकोण का उपयोग करते समय, एक अखंड एसपीए एप्लिकेशन में बहुत अंतर नहीं होगा, जहां सभी लिखित सेवाओं का उपयोग किया जाता है, हालांकि प्रदान किया जाता है : लाइब्रेरी लिखते समय 'रूट' उपयोगी होगा।

पहले, सभी पुस्तकालय सेवाओं को प्रदाताओं से जोड़ा जाना आवश्यक था : [] इसके मॉड्यूल की। पुस्तकालय को आवेदन में आयात करने के बाद, सभी सेवाओं को बंडल में जोड़ा गया था, भले ही केवल एक का उपयोग किया गया हो। प्रदान किए गए मामले में : 'रूट' में लाइब्रेरी मॉड्यूल को जोड़ने की कोई आवश्यकता नहीं है। बस वांछित घटक में सेवा को एम्बेड करें।

विलंबित लोडिंग मॉड्यूल (आलसी) और प्रदान किया गया: 'रूट'

यदि आप प्रदान की गई सेवा को लागू करते हैं तो क्या होता है : आलसी मॉड्यूल में 'रूट' ?

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

सावधान! कई मॉड्यूल में एक सेवा को लागू करने से छिपी निर्भरता हो सकती है जो समझना मुश्किल है और उन्हें सुलझाना असंभव है।

सौभाग्य से, इसे रोकने के तरीके हैं, और हम उन्हें नीचे पर विचार करेंगे।

तुरंत लोड मॉड्यूल (उत्सुक) में निर्भरता इंजेक्शन

एक नियम के रूप में, यह मामला समझ में नहीं आता है और इसके बजाय हम provideIn: 'root' का उपयोग कर सकते हैं। EagerModule में एक सेवा को जोड़ने का उपयोग इनकैप्सुलेशन के लिए किया जा सकता है और मॉड्यूल को कनेक्ट किए बिना कार्यान्वयन को रोक देगा, लेकिन ज्यादातर मामलों में यह आवश्यक नहीं है।

यदि आपको वास्तव में सेवा के दायरे को सीमित करने की आवश्यकता है, तो पुराने प्रदाताओं का उपयोग करना आसान है : [] विधि, क्योंकि यह निश्चित रूप से परिपत्र निर्भरता का कारण नहीं होगा।

यदि संभव हो, तो दिए गए उपयोग का प्रयास करें: सभी उत्सुक मॉड्यूल में 'रूट'।

नोट। विलंबित लोडिंग मॉड्यूल (आलसी) का लाभ

कोणीय की मुख्य विशेषताओं में से एक आवेदन को आसानी से टुकड़ों में विभाजित करने की क्षमता है, जो निम्नलिखित लाभ देता है:

1. आवेदन के मुख्य बंडल का छोटा आकार, जिसके कारण आवेदन लोड होता है और तेजी से शुरू होता है;
2. विलंबित लोडिंग मॉड्यूल अच्छी तरह से अलग-थलग है और एक बार संबंधित मार्ग के लोडचिल्डेन संपत्ति में एक बार आवेदन से जुड़ा हुआ है।

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

आलसी मॉड्यूल के अलगाव का एक और लाभ यह है कि इसमें की गई एक गलती बाकी एप्लिकेशन को प्रभावित नहीं करेगी। अब आप रिलीज के दिन भी शांति से सो सकते हैं।

विलंबित लोडिंग के साथ एक मॉड्यूल में कार्यान्वयन (प्रदान किया गया: LazyModule)

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

दिलचस्प तथ्य: यदि आप आवेदन के मुख्य भाग में आलसी सेवा को लागू करते हैं, तो असेंबली (यहां तक ​​कि एओटी) त्रुटियों के बिना विफल हो जाएगी, लेकिन एप्लिकेशन "आलसी सेवा के लिए कोई प्रदाता नहीं" त्रुटि के साथ दुर्घटनाग्रस्त हो जाएगा।

चक्रीय निर्भरता के साथ समस्या

आप निम्नानुसार त्रुटि को पुन: उत्पन्न कर सकते हैं:

1. LazyModule मॉड्यूल बनाएँ;
2. हम LazyService सेवा बनाते हैं और provideIn का उपयोग कर कनेक्ट करते हैं : LazyModule ;
3. हम LazyComponent घटक बनाते हैं और इसे LazyModule से कनेक्ट करते हैं;
4. LazyService को LazyComponent घटक के निर्माता में जोड़ें;
5. हमें चक्रीय निर्भरता के साथ एक त्रुटि मिलती है।

योजनाबद्ध रूप से, यह इस तरह दिखता है: सेवा -> मॉड्यूल -> घटक -> सेवा ।

आप एक सबमॉडल LazyServiceModule बनाकर इस समस्या को हल कर सकते हैं, जो LazyModule से कनेक्ट की जाएगी । सेवाओं को सबमॉड्यूल से कनेक्ट करें।


इस मामले में, आपको एक अतिरिक्त मॉड्यूल बनाना होगा, लेकिन इसके लिए अधिक प्रयास की आवश्यकता नहीं होगी और निम्नलिखित लाभ देंगे:

1. यह अन्य एप्लिकेशन मॉड्यूल में सेवा की शुरूआत को रोक देगा;
2. एक बंडल में सेवा तभी जोड़ी जाएगी जब यह किसी घटक या मॉड्यूल में उपयोग की जाने वाली अन्य सेवा में एम्बेडेड हो।

घटक में एक सेवा एम्बेड करना (प्रदान की गई: SomeComponent)

क्या नए सिंटैक्स का उपयोग करके @Component या @Directive में किसी सेवा को एम्बेड करना संभव है?

फिलहाल नहीं!

प्रत्येक घटक के लिए सेवा का एक उदाहरण बनाने के लिए, आपको अभी भी प्रदाताओं का उपयोग करने की आवश्यकता है : [] @ omponent या @Directive डेकोरेटर में ।

अनुप्रयोगों में नए सिंटैक्स का उपयोग करने के लिए सर्वोत्तम अभ्यास

पुस्तकालयों

उपलब्ध कराए गए: लाइब्रेरी बनाने के लिए 'रूट' अच्छा है। यह कार्यक्षमता का केवल सीधे इस्तेमाल किए गए कार्य को मुख्य अनुप्रयोग से जोड़ने और अंतिम असेंबली के आकार को कम करने का एक बहुत ही सुविधाजनक तरीका है।

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

आस्थगित डाउनलोड मॉड्यूल (आलसी)

अलग से दिए गए इंक का उपयोग करें : सेवाओं के लिए LazyServicesModule मॉड्यूल और इसे LazyModule में प्लग करें। यह दृष्टिकोण सेवाओं को एनकैप्सुलेट करता है और उन्हें अन्य मॉड्यूल में प्लग करने से रोकता है। यह सीमाओं को निर्धारित करेगा और एक स्केलेबल आर्किटेक्चर बनाने में मदद करेगा।

मेरे अनुभव में, मुख्य या अतिरिक्त मॉड्यूल (प्रोविंड इन: 'रूट' का उपयोग करके) में आकस्मिक परिचय भ्रम की स्थिति पैदा कर सकता है और सबसे अच्छा समाधान नहीं है!

provideIn : 'root' सही ढंग से भी काम करेगा, लेकिन जब provideIn का उपयोग कर रहा है : LazyServideModule हमें अन्य मॉड्यूल में लागू होने पर "लापता प्रदाता" त्रुटि मिलती है और हम आर्किटेक्चर को ठीक कर सकते हैं। एप्लिकेशन के मुख्य भाग में सेवा को अधिक उपयुक्त स्थान पर ले जाएं।

प्रदाताओं का उपयोग कब किया जाना चाहिए: []?

ऐसे मामलों में जहां मॉड्यूल को कॉन्फ़िगर करना आवश्यक है। उदाहरण के लिए, सेवा को केवल SomeModule.forRoot (someConfig) से कनेक्ट करें।



दूसरी ओर, इस स्थिति में, आप provideIn: 'root' का उपयोग कर सकते हैं। यह गारंटी देगा कि सेवा को केवल एक बार आवेदन में जोड़ा जाएगा।

निष्कर्ष

1. प्रदान किया गया प्रयोग करें : 'रूट' एक सिंगलटन के रूप में सेवा को पंजीकृत करने के लिए, पूरे आवेदन में उपलब्ध है।
2. मुख्य बंडल में शामिल मॉड्यूल के लिए, provideIn का उपयोग करें : 'root' , प्रदान नहीं किया गया: EagerlyImportedModule । असाधारण मामलों में, प्रदाताओं का उपयोग करें : [] इनकैप्सुलेशन के लिए।
3. सेवाओं के साथ एक सबमॉड्यूल बनाएं ताकि उनके दायरे को सीमित किया जा सके। आलसी लोडिंग का उपयोग करते समय LazyServiceModule ।
4. वृत्ताकार निर्भरता को रोकने के लिए LazyServiceModule मॉड्यूल को LazyModule में प्लग करें।
5. प्रदाताओं का उपयोग करें : [ omponent और @Directive सज्जाकार में ] प्रत्येक नए घटक उदाहरण के लिए एक नई सेवा आवृत्ति बनाने के लिए। सभी बाल घटकों में एक सेवा उदाहरण भी उपलब्ध होगा।
6. आर्किटेक्चर को बेहतर बनाने और भ्रामक निर्भरताओं से बचने के लिए हमेशा निर्भरता के दायरे को सीमित करें।

संदर्भ

मूल लेख।
कोणीय रूसी भाषी समुदाय है।
रूस में कोणीय बैठक