💪🏻 😒 👈🏿 प्रिज्म डेवलपर की गाइड - भाग 3, घटकों के बीच प्रबंध निर्भरता 🐀 👥 🦃

सामग्री की तालिका
परिचय
प्रारम्भिक प्रिज्म अनुप्रयोग
घटकों के बीच निर्भरता का प्रबंधन
मॉड्यूलर अनुप्रयोग विकास
एमवीवीएम पैटर्न को लागू करना
उन्नत MVVM परिदृश्य
उपयोगकर्ता इंटरफ़ेस निर्माण
उपयोगकर्ता इंटरफ़ेस दिशानिर्देश
नेविगेशन
दृश्य-आधारित नेविगेशन
शिथिल युग्मित घटकों के बीच पारस्परिक क्रिया

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

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

कंटेनर का उपयोग करने के कई फायदे हैं:

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

प्रिज्म पुस्तकालय पर आधारित एक आवेदन के संदर्भ में, कंटेनर का उपयोग करने के कुछ फायदे हैं:

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

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

मुख्य निर्णय: एक निर्भरता इंजेक्शन कंटेनर का चयन

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

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

एकता कई सुविधाएँ प्रदान करती है जो MEF में नहीं हैं:

बिना पंजीकरण के विशिष्ट प्रकार की अनुमति देता है।
सामान्यीकरण ( जेनरिक ) खोलने की अनुमति देता है।
लक्ष्य ( अवरोधन ) में अतिरिक्त कार्यक्षमता जोड़ने के लिए मेथड कॉल इंटरसेप्शन का उपयोग कर सकते हैं।

MEF कई विशेषताएं प्रदान करता है जो एकता में उपलब्ध नहीं हैं:

यह स्वतंत्र रूप से फाइल सिस्टम डायरेक्टरी में असेंबली का पता लगाता है।
लोड XAP फाइलें और उनमें असेंबलियों की तलाश करता है।
जब नए प्रकार की खोज की जाती है, तो संपत्तियों और संग्रहों का पुनर्मिलन करता है।
स्वचालित रूप से व्युत्पन्न प्रकारों का निर्यात करता है।
.NET फ्रेमवर्क के साथ आता है, चौथे संस्करण के साथ शुरू होता है।

कंटेनर क्षमताओं में भिन्न होते हैं और अलग तरह से काम करते हैं, लेकिन प्रिज्म पुस्तकालय किसी भी कंटेनर के साथ काम कर सकता है, वही कार्यक्षमता प्रदान करता है। यह देखते हुए कि किस कंटेनर का उपयोग करना है, अपने पिछले अनुभव को ध्यान में रखें और निर्धारित करें कि कौन सा कंटेनर आपके एप्लिकेशन स्क्रिप्ट के लिए सबसे उपयुक्त है।

कंटेनर विचार

कंटेनरों का उपयोग करने से पहले क्या विचार करें:

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

टिप्पणी
MEF जैसे कुछ कंटेनरों को कॉन्फ़िगरेशन फ़ाइल के माध्यम से कॉन्फ़िगर नहीं किया जा सकता है और उन्हें कोड में कॉन्फ़िगर किया जाना चाहिए।

आधार परिदृश्य

कंटेनरों का उपयोग दो मुख्य उद्देश्यों के लिए किया जाता है, अर्थात् पंजीकरण और अनुमति।

पंजीकरण

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

आमतौर पर, कोड में कंटेनर में प्रकार और वस्तुओं को पंजीकृत करने के दो तरीके हैं:

आप एक प्रकार को पंजीकृत कर सकते हैं, या एक प्रकार से दूसरे में मैप कर सकते हैं। उपयुक्त समय पर, कंटेनर आपके द्वारा निर्दिष्ट प्रकार का एक उदाहरण बनाएगा।
आप किसी ऑब्जेक्ट के मौजूदा उदाहरण को सिंगलटन के रूप में पंजीकृत कर सकते हैं। कंटेनर किसी मौजूदा ऑब्जेक्ट का लिंक लौटाएगा।

UnityContainer में पंजीकरण प्रकार

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

 public class OrderModule : IModule { public void Initialize() { this.container.RegisterType<IOrdersRepository, OrdersRepository>(new ContainerControlledLifetimeManager()); ... } ... }

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

एमईएफ कंटेनर के साथ पंजीकरण प्रकार

कंटेनर में प्रकारों को पंजीकृत करने के लिए, MEF एक विशेषता-आधारित प्रणाली का उपयोग करता है। नतीजतन, कंटेनर में टाइप पंजीकरण को जोड़ना काफी आसान है: इसके लिए, आपको उस प्रकार में [Export] विशेषता को जोड़ना होगा जो आप कंटेनर में पंजीकृत करना चाहते हैं, जैसा कि निम्नलिखित उदाहरण में दिखाया गया है।

 [Export(typeof(ILoggerFacade))] public class CallbackLogger: ILoggerFacade { ... }

MEF के लिए एक और उपयोग मामला हो सकता है कि वह उस वर्ग को तत्काल भेज दे और उस विशेष उदाहरण को कंटेनर में पंजीकृत कर दे। MEF क्विकस्टार्ट के साथ सिल्वरलाइट के लिए मॉड्यूलरिटी में QuickStartBootstrapper कंफर्टकॉनटेनर विधि में इसका एक उदाहरण दिखाता है।

 protected override void ConfigureContainer() { base.ConfigureContainer(); //    CallbackLogger,     , //    ,     (),   . this.Container.ComposeExportedValue<CallbackLogger>(this.callbackLogger); }

टिप्पणी
कंटेनर के रूप में MEF का उपयोग करते समय, यह अनुशंसा की जाती है कि आप पंजीकरण प्रकारों के लिए विशेषताओं का उपयोग करें।

परमिट

एक बार एक प्रकार पंजीकृत होने के बाद, इसे एक निर्भरता के रूप में हल या कार्यान्वित किया जा सकता है। जब एक प्रकार हल हो जाता है, और कंटेनर को इस प्रकार का एक नया उदाहरण बनाना होगा, तो यह इस उदाहरण में निर्भरता को इंजेक्ट करता है।

सामान्य तौर पर, जब एक प्रकार का समाधान किया जाता है, तो तीन चीजों में से एक होता है:

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

एकता का संकल्प

कमांडिंग क्विकस्टार्ट के निम्नलिखित कोड उदाहरण से पता चलता है कि कैसे कंटेनर से OrdersEditorView और OrdersToolBar को उनके संबंधित क्षेत्रों में बाँधने के लिए हल किया जाता है।

 public class OrderModule : IModule { public void Initialize() { this.container.RegisterType<IOrdersRepository, OrdersRepository>(new ContainerControlledLifetimeManager()); //   Orders Editor    . this.regionManager.RegisterViewWithRegion("MainRegion", () =>; this.container.Resolve<OrdersEditorView>()); //   Orders Toolbar    . this.regionManager.RegisterViewWithRegion("GlobalCommandsRegion", () => this.container.Resolve<OrdersToolBar>()); } ... }

OrdersEditorPresentationModel कंस्ट्रक्टर में निम्न निर्भरताएं (ऑर्डर रिपॉजिटरी और ऑर्डर कमांड प्रॉक्सी) शामिल हैं जो इसे हल किए जाने पर पेश की जाती हैं।

 public OrdersEditorPresentationModel(IOrdersRepository ordersRepository, OrdersCommandProxy commandProxy) { this.ordersRepository = ordersRepository; this.commandProxy = commandProxy; //     . this.PopulateOrders(); //  CollectionView    . #if SILVERLIGHT this.Orders = new PagedCollectionView( _orders ); #else this.Orders = new ListCollectionView( _orders ); #endif //   . this.Orders.CurrentChanged += SelectedOrderChanged; this.Orders.MoveCurrentTo(null); }

एक निर्माता में एम्बेड करने के अलावा, जैसा कि पिछले उदाहरण में दिखाया गया है, एकता गुणों में निर्भरता को भी एम्बेड कर सकती है। कोई भी गुण जिसके लिए [Dependency] विशेषता को लागू किया जाता है, स्वचालित रूप से हल और कार्यान्वित किया जाता है जब ऑब्जेक्ट हल किया जाता है। यदि संपत्ति को OptionalDependency निर्भरता विशेषता के साथ चिह्नित किया जाता है, तो यदि निर्भरता को हल करना संभव नहीं है, तो संपत्ति को null सेट किया जाता है और कोई अपवाद नहीं फेंका जाता है।

MEF में उदाहरणों का समाधान

निम्न कोड उदाहरण दिखाता है कि MEF क्विकस्टार्ट के साथ सिल्वरलाइट के लिए मॉड्यूलरिटी में Bootstrapper एक शेल उदाहरण कैसे प्राप्त करता है। एक विशिष्ट प्रकार का अनुरोध करने के बजाय, कोड इंटरफ़ेस के एक उदाहरण का अनुरोध कर सकता है।

 protected override DependencyObject CreateShell() { return this.Container.GetExportedValue<Shell>(); }

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

 [ImportingConstructor] public ModuleA(ILoggerFacade logger, IModuleTracker moduleTracker) { if (logger == null) { throw new ArgumentNullException("logger"); } if (moduleTracker == null) { throw new ArgumentNullException("moduleTracker"); } this.logger = logger; this.moduleTracker = moduleTracker; this.moduleTracker.RecordModuleConstructed(WellKnownModuleNames.ModuleA); }

वैकल्पिक रूप से, आप संपत्ति इंजेक्शन का उपयोग कर सकते हैं, जैसा कि MEF क्विकस्टार्ट के साथ सिल्वरलाइट के लिए मॉड्यूलरिटी के ModuleTracker वर्ग में दिखाया गया है, जिसमें एक एम्बेडेड ILoggerFacade का उदाहरण है।

 [Export(typeof(IModuleTracker))] public class ModuleTracker : IModuleTracker { // -  Silverlight/MEF,    . [Import] public ILoggerFacade Logger; }

टिप्पणी
सिल्वरलाइट में, आयातित गुण और क्षेत्र सार्वजनिक होने चाहिए।

प्रिज्म में निर्भरता इंजेक्शन कंटेनरों और सेवाओं का उपयोग करना

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

प्रिज्म लाइब्रेरी UnityServiceLocatorAdapter और MefServiceLocatorAdapter प्रदान MefServiceLocatorAdapter । दोनों एडेप्टर ISeviceLocator इंटरफ़ेस को कार्यान्वित करते हैं, ServiceLocatorImplBase प्रकार का विस्तार करते हैं। निम्नलिखित चित्रण वर्ग पदानुक्रम को दर्शाता है।

प्रिज्म में सामान्य सेवा लोकेटर कार्यान्वयन।

प्रिज्म में सामान्य सेवा लोकेटर कार्यान्वयन।

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

IServiceLocator

निम्न कोड IServiceLocator इंटरफ़ेस और उसके तरीकों को दर्शाता है।

 public interface IServiceLocator : IServiceProvider { object GetInstance(Type serviceType); object GetInstance(Type serviceType, string key); IEnumerable<object> GetAllInstances(Type serviceType); TService GetInstance<TService>(); TService GetInstance<TService>(string key); IEnumerable<TService> GetAllInstances<TService>(); }

सेवा लोकेटर निम्नलिखित कोड में दिखाए गए विस्तार विधियों के साथ प्रिज्म पुस्तकालय का पूरक है। आप देख सकते हैं कि IServiceLocator उपयोग केवल अनुमति के लिए किया जाता है, और पंजीकरण के लिए नहीं।

 public static class ServiceLocatorExtensions { public static object TryResolve(this IServiceLocator locator, Type type) { try { return locator.GetInstance(type); } catch (ActivationException) { return null; } } public static T TryResolve<T>(this IServiceLocator locator) where T: class { return locator.TryResolve(typeof(T)) as T; } }

TryResolve एक्सटेंशन TryResolve , जिसे यूनिटी कंटेनर समर्थन नहीं करता है, उस प्रकार का एक उदाहरण देता है जिसे पंजीकृत होने पर अनुमति दी जानी चाहिए, अन्यथा यह null ।

मॉड्यूल ModuleInitializer लोड होते समय मॉड्यूल निर्भरता को हल करने के लिए IServiceLocator का उपयोग करता है, जैसा कि निम्नलिखित कोड उदाहरणों में दिखाया गया है।

 IModule moduleInstance = null; try { moduleInstance = this.CreateModule(moduleInfo); moduleInstance.Initialize(); } ...

 protected virtual IModule CreateModule(string typeName) { Type moduleType = Type.GetType(typeName); if (moduleType == null) { throw new ModuleInitializeException(string.Format(CultureInfo.CurrentCulture, Properties.Resources.FailedToGetType, typeName)); } return (IModule)this.serviceLocator.GetInstance(moduleType); }

IServiceLocator का उपयोग करने के लिए विचार

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

निम्नलिखित स्थितियों में, IServiceLocator का उपयोग उचित है:

आप एक स्वतंत्र सॉफ़्टवेयर विक्रेता (ISV) हैं जो एक तृतीय-पक्ष सेवा विकसित कर रहे हैं जिसे कई कंटेनरों का समर्थन करना चाहिए।
आप एक ऐसी सेवा विकसित कर रहे हैं जिसका उपयोग विभिन्न कंटेनरों का उपयोग करने वाले संगठन में किया जाएगा।

अतिरिक्त जानकारी

DI कंटेनरों से संबंधित जानकारी के लिए, देखें:

MSDN पर "एकता अनुप्रयोग ब्लॉक": http://www.msdn.com/unity
CodePlex पर एकता समुदाय साइट: http://www.codeplex.com/unity
MSDN पर "प्रबंधित एक्स्टेंसिबिलिटी फ्रेमवर्क ओवरव्यू" http://msdn.microsoft.com/en-us/library/dd460648.aspx
कोडप्‍लेक्स पर MEF समुदाय साइट: http://mef.codeplex.com/
मार्टिन फाउलर की वेबसाइट पर "कंट्रोल कंटेनर्स और डिपेंडेंसी इंजेक्शन पैटर्न का उलटा": http://www.martinfowler.com/articles/injection.html
MSDN पत्रिका में "डिज़ाइन पैटर्न: निर्भरता इंजेक्शन": http://msdn.microsoft.com/en-us/magazine/cc163739.aspx
MSDN मैगज़ीन में "ढीले अप: अधिक लचीले ऐप्स के लिए अपने सॉफ़्टवेयर निर्भरताओं को वश में रखें": http://msdn.microsoft.com/en-us/magazine/cc337885.aspx
कैसल प्रोजेक्ट: http://www.castleproject.org/container/index.html
स्ट्रक्चुरपेज़: http://structurcodeap.sourceforge.net/Default.htm
स्प्रिंग.नेट: http://www.springframework.net/

प्रिज्म डेवलपर की गाइड - भाग 3, घटकों के बीच प्रबंध निर्भरता