अतिरिक्त संकेतक परत के लायक निर्भरता इंजेक्शन ढांचे हैं?

Question

क्या आप पाते हैं कि निर्भरता इंजेक्शन ढांचे कोड को और अधिक कठिन बनाने के लिए बनाते हैं? क्या संकेत लाभ से अधिक है?

Answer 1

हां, आपका कोड अधिक decoupled और अधिक परीक्षण योग्य हो जाता है। यह विशेष रूप से आसान हो जाता है जब आपके पास बहुत सारे परीक्षण होते हैं और प्रत्येक परीक्षण के लिए डेटाबेस परतों जैसे भारी वस्तु की आवश्यकता होती है।

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

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

Answer 2

मुझे लगता है कि लाभ इस बात पर निर्भर करता है कि आप इसका उपयोग कैसे करते हैं।

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

Answer 3

मेरी राय निर्भरता में- इंजेक्शन ढांचे कोड को पढ़ने के लिए और अधिक जटिल नहीं बनाते हैं। तथ्य यह है कि आप केवल इंटरफेस के संदर्भ देखते हैं और कंक्रीट कार्यान्वयन के संदर्भ नहीं हैं - क्योंकि आपको इस पर ध्यान नहीं देना चाहिए कि कंक्रीट कार्यान्वयन कैसे काम करता है।

यदि स्रोत कोड के माध्यम से नेविगेट भी मुश्किल है, Resharper हो और सब कुछ ठीक है।

Answer 4

गैर-तुच्छ "enterprisey" ऐप्स के लिए, हाँ यह इसके लायक है। डी ढांचे से पहले, प्रत्येक दुकान ने अपनी अन्य परियोजनाओं का उपयोग करने वाली कुछ आंतरिक पुस्तकालयों में अपनी खुद की फैंसी "सर्विसलोकेटर" कक्षा लागू की। तो आपने कोडबेज भर में उस चीज़ को बुलाया था।

उन कॉलों ने वस्तुओं की अपनी निर्भरताओं को खोजने/कॉन्फ़िगर करने की आवश्यकता का प्रतिनिधित्व किया। डी ढांचा सभी कोड को समाप्त करता है, इसलिए आपकी वस्तुएं सरल हो जाती हैं और इसलिए परीक्षण करना आसान होता है।

अब, यह इस प्रकार है कि अगर आप अपने वस्तुओं 'निर्भरता में परिवर्तनशीलता का एक बहुत जरूरत नहीं है, अविवेक (केंद्रीकृत विन्यास) का मूल्य आप के लिए कम है।

अधिक जानकारी के ServiceLocator को डि विषम के लिए, देखें फाउलर की Inversion of Control Containers and the Dependency Injection pattern

Answer 5

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

हालांकि, नियंत्रण में उलटा जाने का एकमात्र तरीका नहीं है। एक सहयोगी ने JNDI के अपने कार्यान्वयन को लिखकर इसे हासिल किया है। मुझे चारों ओर जीतने में काफी समय लगा लेकिन यह शानदार है और इसमें एक विशिष्ट Spring प्रोजेक्ट की कॉन्फ़िगरेशन का एक अंश है।

Answer 6

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

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

हम मच्छर को एक बड़ी बंदूक लेते हैं क्योंकि बंदूक शांत दिखती है।

पी

Answer 7

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

For DI Framework

Against DI Framework

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

Answer 8

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

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

आप निर्भरताओं को खत्म नहीं कर सकते हैं, लेकिन आप निश्चित रूप से एक्सएमएल कॉन्फ़िगरेशन फ़ाइल में उनमें से बिल्ली को खराब कर सकते हैं। किसी बिंदु पर कुछnew पर कॉल करने जा रहा है। क्या आप वास्तव में किसी भी इंटरफ़ेस के कार्यान्वयन को बिना किसी संकल्प या रीस्टेस्टिंग किए जा रहे हैं? यदि नहीं, तो इसे सरल रखें। "परिभाषा खोजें" पर क्लिक करना और स्पष्ट सिंगलटन या ThreadStatic या किसी अन्य व्यवहार के साथ सेवा लोकेटर कक्षा में वास्तव में तत्काल कुछ प्राप्त करना अच्छा लगता है।

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

Answer 9

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

1. ऑब्जेक्ट बनाने के लिए नया उपयोग करें।
   मैं को में इसे वितरित करने के लिए प्रोजेक्ट को पुन: संकलित करना होगा। एक विशाल नकारात्मक: परीक्षण, तैनाती, नई कोड शाखा आदि बनाए रखना होगा
2. फैक्टरी का उपयोग करें।
   मेरा कोड को कोड के साथ छिड़क दिया जाएगा जो फैक्टरी पर पकड़ लेता है और उदाहरण प्राप्त करता है। इसके अलावा, मैं को एक सामान्य उदाहरण वापस करना होगा और इसे ऑब्जेक्ट की अपेक्षा के अनुसार डालना होगा। यदि नहीं, तो फैक्टरी इंटरफ़ेस को बदलने के लिए होगा, प्रत्येक जब मैं फैक्ट्री द्वारा बनाई गई नई वस्तु जोड़ता हूं।
3. सेवा लोकेटर का उपयोग करें।
   इसी तरह के 2 के रूप में। केवल सेवा के आधार पर लोकेटर हमेशा जावा जेएनडीआई जैसे के आसपास नहीं हो सकता है।

DI इसे बाहरी करता है और यह दृष्टिकोण लेता है कि इंजेक्शन अलग चिंता है। आपकी ऑब्जेक्ट को डोमेन से संबंधित होना चाहिए और उपयुक्त सहयोगियों को ढूंढना नहीं चाहिए।