निर्भरता इंजेक्शन (DI) और नियंत्रण के व्युत्क्रम (IOC) के बीच अंतर

117

मैं डिपेंडेंसी इंजेक्शन (DI) और नियंत्रण के व्युत्क्रम (IOC) के बहुत सारे संदर्भ देख रहा हूं, लेकिन मुझे वास्तव में नहीं पता है कि उनके बीच कोई अंतर है या नहीं।

मैं उनमें से एक या दोनों का उपयोग करना शुरू करना चाहता हूं, लेकिन मैं थोड़ा भ्रमित हूं कि वे कैसे अलग हैं।

dependency-injection inversion-of-control

— कुटकी
स्रोत

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

— बेन हॉफस्टीन

डिपेंडेंसी इंजेक्शन एक ऐसी चीज़ है जो आप करते हैं, जो एक कमांड स्ट्रक्चर की ओर ले जाती है जिसे इन्वर्ट ऑफ कंट्रोल कहते हैं। वे स्वाभाविक रूप से जुड़े हुए हैं।

2

डि आईओसी का एक रूप है, मैंने इस उत्तर

2

मैं कहूंगा कि DI IOC का एक विशेष मामला है। पारंपरिक नियंत्रण मॉड्यूल-> मॉड्यूल प्रबंधक से मॉड्यूल का अनुरोध करता है, डि में यह मॉड्यूल प्रबंधक से उलटा है-> मॉड्यूल से अनुरोधित निर्भरताएं प्राप्त करें।

— राफेल डाउगर्ड

तो दूसरे शब्दों में, मूल रूप से IoC DI का उपयोग करने का एक कार्यान्वयन है। क्या मुझे वह सही लग रहा है?

— डांस 2

53

परिभाषाएं

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

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

साथ में काम कर रहे

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

उदाहरण

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

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

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

सारांश

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

— चक
स्रोत

3

नहीं, IoC एक पुरानी अवधारणा है और यह DI से स्वतंत्र है (जो IoC पर निर्भर नहीं है)। उदाहरण के लिए, स्ट्रट्स ढांचे (जावा) को लें: यह आईओसी पर बहुत निर्भर करता है, लेकिन डीआई का कोई उपयोग नहीं करता है।

— रोजेरियो

1

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

— चक

IoC का सबसे सरल अनुप्रयोग, शायद ActionListener होगा। कोड को प्रक्रियात्मक रूप से संभालने के बजाय, ईवेंट हैंडलिंग कोड को कस्टम कोड को सौंप दिया जाता है। जिससे नियंत्रण खत्म हो गया।

— माइक

0

IOC और DI को समझने के लिए अच्छा लेख http://martinfowler.com/articles/injection.html

IOC (नियंत्रण का उलटा)

आईओसी का मतलब है

इंटरफ़ेस के लिए कोडिंग (एक घटक को अन्य घटक के इंटरफ़ेस पर निर्भर होना चाहिए और न ही निहित होना चाहिए), और उदा
```
interface iComp_2 {...}

class Comp_1 {
    iComp_2 c2 = ….;
}
```
घटक कार्यान्वयन विशिष्ट कोड को हटाना जैसे
```
Comp_1 {
    iComp_2 c2 = getComp_2_Impl(); // not new Comp_2_Impl();
}
```

निम्नलिखित में से IOC प्राप्त किया जा सकता है:

1. डि (निर्भरता इंजेक्शन)

3 types of DI

1.1 Constructor Injection

1.2 Setter Injection

1.3 Interface Injection

2. सेवा लोकेटर

डि (निर्भरता इंजेक्शन) कंटेनर

रनटाइम निर्धारण का निर्धारण और संकलन समय नहीं: रनटाइम पर निर्धारित होता है कि किसी कॉन्फिगरेशन के ठोस कार्यान्वयन का उपयोग कुछ कॉन्फिगर फाइल के आधार पर किया जाता है (इसलिए संकलन समय पर हमें नहीं पता होता है कि कौन सा इम्प्लांट इस्तेमाल होने वाला है और इस तरह एप्लिकेशन की कॉन्फ़िगरेशन क्षमता बढ़ जाती है) । यह एक कार्यान्वयन है जहां विभिन्न मॉड्यूल के बीच ठोस संबंध "रन टाइम" पर तय किया जाता है।

डिपेंडेंसी इंजेक्शन के बाद इम्प्लांट की तात्कालिकता: इम्प्लांट को निर्धारित करने के बाद, यह इंस्टेंटिअट्स को पहले अपनी सभी निर्भरता (कॉन्फिग फाइल में निर्दिष्ट) बनाकर और फिर उन इम्प्लिकेशन्स को उस इंपैक्ट में इंजेक्ट करता है।

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

— यतेंद्र गोयल
स्रोत

6

क्या आपने वास्तव में "इंजेक्शन" लेख पढ़ा है? आईओसी का मतलब यह नहीं है कि यह उत्तर क्या कहता है, बिल्कुल नहीं।

— रोजेरियो

-3

मैं कहूंगा कि "इनवर्टर ऑफ कंट्रोल" एक ऐसी प्रणाली को डिजाइन करने का एक तरीका है जहां सभी मॉड्यूल अमूर्त संस्थाओं के बारे में सोचा जाता है।

और, "निर्भरता इंजेक्शन" एक कार्यान्वयन है जहां विभिन्न मॉड्यूल के बीच ठोस संबंध "रन टाइम" पर तय किया जाता है।

— MB।
स्रोत

-4

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

— जेवियर
स्रोत