2009-04-20 25 views
41

क्या किसी के पास आईओसी कंटेनर (अधिमानतः सी # में) के अच्छे उदाहरण हैं और उन्हें कैसे और क्यों उपयोग करें? मैंने wiki page और Ayende's उदाहरण की जांच की है, लेकिन मुझे अभी तक अवधारणा नहीं मिल रही है।आईओसी कंटेनर के उदाहरण

और मुझे कब और कहां आईओसी कंटेनर का उपयोग करना चाहिए?

उत्तर

47

मैंने structure map का उपयोग किया है। आपका बाकी का सवाल बहुत भरा हुआ है। मैं एक उदाहरण में अवधारणा को समझाने की कोशिश करूंगा।

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

इसके बजाय आप बन जाएगा और कोड इस तरह एक अंतरफलक के खिलाफ ..

interface IPaymentProcessor 
{ 
     bool ProcessPayment(amount, ....); 
} 

सभी अपने पेपैल कोड एक वर्ग है कि अपने इंटरफेस के तरीकों को लागू करता है में रहते हैं होगा। उदाहरण के लिए PayPalPaymentProcessor

अब आपके पास एक ऑब्जेक्ट है जिसका उपयोग आप वास्तव में भुगतान को संसाधित करने के लिए करेंगे। यह एक नियंत्रक (asp.net-mvc, ViewModel-wpf) हो सकता है या यहां दिखाया गया एक वर्ग हो सकता है।

class PaymentProcessor 
{ 
    private IPaymentProcessor _processor = null; 
    public PaymentProcessor(IPaymentProcessor processor) 
    { 
     _processor = processor; 
    } 

    public bool ProcessTransaction(Transaction trans) 
    { 
     _processor.ProcessPayment(trans.amount, ...); 
    } 
} 

यह जहां एक आईओसी में आता है। इसके बजाय आप निर्माता मैन्युअल बुलाने की, तो आप एक आईओसी इंजेक्षन निर्भरता दिया जाएगा।

PaymentProcessor processor = ObjectFactory.GetInstance<PaymentProcessor>(); 

कोड का यह टुकड़ा संरचना नक्शा कहता है "जब भी आप एक निर्माता एक IPaymentProcessor की जरूरत है कि देखते हैं, एक नया PayPalPaymentProcessor वापसी"।

ObjectFactory.Initialize(x => 
{ 
x.ForRequestedType<IPaymentProcessor>().TheDefaultIsConcreteType<PayPalPaymentProcessor>(); 
}); 

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

आशा है कि इससे मदद मिलती है!

+0

अच्छा उदाहरण के लिए धन्यवाद :)। मैं समझता हूं कि प्रश्न का अंतिम भाग थोड़ा व्यापक है, लेकिन मुझे लगता है कि आपने उस हिस्से का जवाब भी दिया है। – Morph

+0

क्या मैं एक सुधार का सुझाव दे सकता हूं? क्या कोड नहीं होना चाहिए जहां भुगतानप्रोसेसर को उदाहरण मिल जाए? 'भुगतानप्रोसेसर प्रोसेसर = ऑब्जेक्ट फैक्ट्री। गेट इंस्टेंस ();' –

2

Spring IoC (.net) एक जावा/.नेट कंटेनर देखें। दस्तावेज़ीकरण काफी अच्छा परिचय है।

एक संक्षेप में: वस्तुओं रचना और प्रोग्रामिंग इंटरफेस रहे हैं: आप एक वास्तुकला कि प्रोत्साहित करते हैं के रूप में आईओसी के बारे में सोच सकते हैं।

यह आप निम्नलिखित देता है:

  • इकाई की क्षमता आसानी से अपने कोड का परीक्षण (आप आसानी से अपने सभी निर्भरता को मजाक से अलगाव में अपनी वस्तुओं का परीक्षण कर सकते हैं)।

  • एक बेहद अग्रिम कॉन्फ़िगरेशन (क्योंकि आईओसी के साथ आपका प्रोग्राम ऑब्जेक्ट्स का एक समूह है और एक कॉन्फ़िगरेशन जो ऑब्जेक्ट्स को एक साथ चिपकाता है)।

  • बाइट संकलित अनुप्रयोग को विस्तारित या संशोधित करने की क्षमता (यह जावा के लिए सच है मुझे यकीन नहीं है कि यह .NET के लिए सही है)।

+0

धन्यवाद जो एक अच्छा पढ़ना पसंद है! – Morph

0

क्या आप एक आईओसी कंटेनर बनाने की कोशिश कर रहे हैं क्यों स्प्रिंग.NET, स्ट्रक्चर मैप या यूनिटी एप्लिकेशन ब्लॉक जैसे उपलब्ध लोगों में से एक का उपयोग न करें? Here ओपन-सोर्स आईओसी परियोजनाओं की एक सूची है

+1

नहीं, मैं अभी तक एक बनाने की कोशिश नहीं कर रहा हूं, यह अवधारणा है जिसे मैं बेहतर समझने की कोशिश कर रहा हूं। – Morph

1

मैं आमतौर पर StructureMap का उपयोग करता हूं - अधिकतर क्योंकि मैं वाक्यविन्यास से परिचित हूं। मैंने autofac के बारे में अच्छी बातें भी सुनी हैं और जब मैं v2 हिट करता हूं तो Ninject को आजमाने की उम्मीद कर रहा हूं।

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

2

हम अपने सरल एपीआई और वस्तुओं के तेज़ संकल्प के कारण निनजेक्ट का उपयोग करते हैं। यह बहुत अच्छी तरह से प्रलेखित है और विनिर्देशों को आसान बनाने के लिए लैम्ब्डा अभिव्यक्तियों जैसे सी # 3.0 फीचर्स का लाभ उठाता है।

आप Ninject here

0

मैं अपने आईओसी कंटेनर के लिए एकता का उपयोग कर रहा हूं, लेकिन कंटेनरों के बीच का अंतर DI के साथ आप जो भी कर सकते हैं उससे अधिक में रहता है।

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

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

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

8

यदि आप हुड के नीचे एक आईओसी कंटेनर देखना चाहते हैं, और बिंदु (निर्भरता इंजेक्शन) भी है, तो डीएनआर टीवी (Episode 126) पर एक महान पॉडकास्ट है जो वास्तव में उन्हें बनाने के बारे में विस्तार से बताता है, आप क्यों चाहते हैं उनकी जरूरत। यह वास्तव में एक अद्भुत पॉडकास्ट है। एक बार जब आप इस वीडियो को देखा है, तो आप Unity, Ninject, StructureMap, आदि को देखने और समझने के लिए वे क्या कर रहे

19

आईओसी कंटेनर के नीचे दी गई सीमाओं के प्रति सचेत रहें सक्षम होने के लिए सक्षम हो जाएगा। मुझे लोगों को चेतावनी देना है, क्योंकि मैं इसका उपयोग कर सिस्टम का समर्थन करने के नरक के साथ रह रहा हूं:

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

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

+13

आप किस कंटेनर का उपयोग कर रहे हैं? यह वास्तव में भयानक होना चाहिए - आज व्यापक रूप से उपयोग किए जाने वाले कंटेनर में इन सीमाएं नहीं हैं ("भूल गए पंजीकरण" मुद्दे को छोड़कर।) –

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