IoC, DI, IoC कंटेनर - बस सरल के बारे में

मुझे लगता है कि अब आईओसी, डीआई, आईओसी-कंटेनर शब्द कम से कम कई की सुनवाई में हैं। कुछ सक्रिय रूप से इसका उपयोग कर रहे हैं, जबकि अन्य यह समझने की कोशिश कर रहे हैं कि यह किस तरह का फैशन ट्रेंड है।

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

सिद्धांत

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

अभ्यास

प्रबंधन उलटा दृष्टिकोण के अनुसार, यदि हमारे पास एक ग्राहक है जो एक निश्चित सेवा का उपयोग करता है, तो उसे सीधे ऐसा नहीं करना चाहिए, लेकिन एक मध्यस्थ के माध्यम से, एक प्रकार की आउटसोर्सिंग।

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

class ScheduleManager { public Schedule GetSchedule() { // Do Something by init schedule... } } class ScheduleViewer { private ScheduleManager _scheduleManager = new ScheduleManager(); public void RenderSchedule() { _scheduleManager.GetSchedule(); // Do Something by render schedule... } } 

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

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

 interface IScheduleManager { Schedule GetSchedule(); } class ScheduleManager : IScheduleManager { public Schedule GetSchedule() { // Do Something by init schedule... } } class ScheduleViewer { private IScheduleManager _scheduleManager; public ScheduleViewer(IScheduleManager scheduleManager) { _scheduleManager = scheduleManager; } public void RenderSchedule() { _scheduleManager.GetSchedule(); // Do Something by render schedule... } } 

और फिर जहां हम अनुसूची प्रदर्शित करने के लिए अपनी कक्षा का उपयोग करना चाहते हैं, हम लिखते हैं:

 ScheduleViewer scheduleViewer = new ScheduleViewer(new ScheduleManager()); 

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

आईओसी कंटेनर

वे दिनचर्या की मात्रा को कम करने में मदद करते हैं, जिससे आप इंटरफ़ेस और इसके विशिष्ट कार्यान्वयन के बीच पत्राचार सेट कर सकते हैं, ताकि आप इसे बाद में हर जगह उपयोग कर सकें।
जैसा कि मैंने ऊपर कहा था, हम इस पर विचार करेंगे।
1. सबसे पहले हम एक कंटेनर कॉन्फ़िगरेशन बनाते हैं:

 class SimpleConfigModule : NinjectModule { public override void Load() { Bind<IScheduleManager>().To<ScheduleManager>(); //   ,     : // ..     Bind<ScheduleViewer>().ToSelf(); } } 

अब जहाँ भी आवश्यकता होगी, IScheduleManager को ScheduleManager प्रतिस्थापित किया जाएगा।
2. कन्टेनर स्वयं बनाएं, इसके विन्यासकर्ता को दर्शाता है:

 IKernel ninjectKernel = new StandardKernel(new SimpleConfigModule()); //      ScheduleViewer   new,  : ScheduleViewer scheduleViewer= ninjectKernel.Get<ScheduleViewer>(); 

कंटेनर खुद ही शेड्यूल मैनजर क्लास का एक उदाहरण बनाता है, शेड्यूलव्यूअर कंस्ट्रक्टर को कॉल करता है, और इसमें शेड्यूलमैनेजर का एक नया बनाया गया उदाहरण देता है।

निष्कर्ष

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