.NET में मार्क सीमन की पुस्तक डिपेंडेंसी इंजेक्शन की समीक्षा

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


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

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

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

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

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

पहले तीन भागों के दौरान, कोई भी कंटेनरों का उपयोग नहीं किया जाता है, और सभी उदाहरण "स्व-निर्मित" निर्भरता प्रबंधन (तथाकथित गरीब आदमी का डीआई) का उपयोग करते हैं।

उद्धरण
एक DI कंटेनर सिर्फ एक उपकरण है, और किसी भी उपकरण की तरह, इसका सही तरीके से उपयोग किया जा सकता है, या इसका गलत तरीके से उपयोग किया जा सकता है।

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

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

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

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

उद्धरण
आवेदन में सीम जोड़ने से अतिरिक्त प्रयासों की आवश्यकता होती है, इसलिए उन्हें जोड़ना केवल आवश्यक होने पर आवश्यक है।
(इंटरफेस को हाइलाइट करने और अतिरिक्त एप्लिकेशन सीम बनाने के बारे में चिह्नित करें)

इस पुस्तक में एक खामी है - यह अंतिम चौथा भाग है, जिसमें छह DI कंटेनरों का वर्णन किया गया है। मुझे यह आभास हुआ कि लेखक ने माना है कि 350 पृष्ठों की पुस्तक ठोस नहीं दिखती है, या उसके लिए मुख्य KPI सिर्फ पृष्ठों की संख्या थी।

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

संक्षेप में , मैं कहना चाहता हूं कि ".NET में निर्भरता इंजेक्शन" निर्भरता प्रबंधन पर जानकारी का सबसे व्यापक और सुसंगत स्रोत है। मैं इस पुस्तक के पहले 3 भागों को उन सभी टीमों को पढ़ने के लिए सुझाऊंगा जो अपनी परियोजनाओं में DI कंटेनरों का उपयोग करते हैं।

रेटिंग : 5+ (भागों 1-3 के लिए) और 2 (भाग 4 के लिए)।