2008-11-10 7 views
10

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

नीचे आईओसी आवरण है:

public static class IoC 
    { 
     private static IDependencyResolver inner; 

     public static void InitWith(IDependencyResolver container) 
     { 
      inner = container; 
     } 

     /// <exception cref="InvalidOperationException">Container has not been initialized. Please supply an instance if IWindsorContainer.</exception> 
     public static T Resolve<T>() 
     { 
      if (inner == null) 
       throw new InvalidOperationException("Container has not been initialized. Please supply an instance if IWindsorContainer."); 

      return inner.Resolve<T>(); 
     } 

     public static T[] ResolveAll<T>() 
     { 
      return inner.ResolveAll<T>(); 
     } 
    } 

IDependencyResolver:

public interface IDependencyResolver 
    { 
     T Resolve<T>(); 
     T[] ResolveAll<T>(); 
    } 

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

क्या यह एक फिसलन सड़क है? क्या मैं सड़क के नीचे संभावित मुद्दों में भागने जा रहा हूं?

उत्तर

4

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

हालांकि, एक विकल्प के रूप में, आप हमेशा अपने कंटेनर के संदर्भ के रूप में IDependencyResolver को हल करने के लिए अपने कंटेनर को कॉन्फ़िगर कर सकते हैं। यह पागल लग सकता है, लेकिन यह काफी अधिक लचीला है। बस अंगूठे के नियम को याद रखें कि किसी ऑब्जेक्ट को "नया" या प्रोसेसिंग करना चाहिए, लेकिन दोनों नहीं। "संदर्भ को हल करें" के साथ "नया कॉल करें" के लिए प्रतिस्थापित करें।

3

यह वास्तव में एक सिंगलटन वर्ग नहीं है। यह स्थैतिक सदस्यों के साथ एक स्थिर वर्ग है। और हाँ यह एक अच्छा दृष्टिकोण लगता है।

मुझे लगता है कि जेपी बुडू भी इस पैटर्न के लिए एक नाम है। The Static Gateway pattern

2

बस एक नोट: माइक्रोसॉफ्ट पैटर्न और प्रथाओं ने एक सामान्य सेवा लोकेटर (http://www.codeplex.com/CommonServiceLocator) बनाया है कि अधिकांश प्रमुख आईओसी कंटेनर निकट भविष्य में कार्यान्वित हो रहे हैं। आप अपने आईडी निर्भरता रीसोलवर के बजाय इसका उपयोग शुरू कर सकते हैं।

बीटीडब्लू: यह आपकी समस्या का समाधान करने का एक आम तरीका है और यह काफी अच्छी तरह से काम करता है।

1

यह सब उपयोग पर निर्भर करता है। इस तरह के कंटेनर का उपयोग सेवा लोकेटर पैटर्न कहा जाता है। ऐसे मामले हैं जहां यह एक अच्छा फिट नहीं है और जहां यह लागू होता है।

यदि आप "सेवा लोकेटर पैटर्न" पर Google हैं तो आपको बहुत से ब्लॉग पोस्ट दिखाई देंगे, यह कहकर कि यह एक विरोधी पैटर्न है, जो यह नहीं है। पैटर्न को अत्यधिक उपयोग किया गया है (/ दुरुपयोग)।

व्यावसायिक अनुप्रयोगों की सामान्य रेखा के लिए आपको निर्भरता को छिपाने के रूप में SL का उपयोग नहीं करना चाहिए। आपको एक और समस्या भी मिली है: यदि आप रूट कंटेनर (इसके जीवनकाल में से किसी एक के बजाय) का उपयोग करते हैं तो आप राज्य/जीवनकाल का प्रबंधन नहीं कर सकते हैं।

सेवा लोकेटर बुनियादी ढांचे की बात करते समय एक अच्छा फिट है। उदाहरण के लिए एएसपी.नेट एमवीसी प्रत्येक नियंत्रक के लिए सभी निर्भरताओं को हल करने में सक्षम होने के लिए सेवा लोकेटर का उपयोग करता है।

संबंधित मुद्दे