व्यक्तिगत सेवाओं की बजाय सेवा कंटेनर इंजेक्शन से बचने के तकनीकी कारण क्या हैं?

Question

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

Answer 1

यदि आप कंटेनर इंजेक्ट करते हैं, तो आप निर्भरता को स्पष्ट नहीं कर रहे हैं। वास्तव में, आप उन्हें पहले से अधिक अस्पष्ट कर रहे हैं। यदि आपके पास इस तरह की कक्षा है ...

class DocumentCreator(IFileNamer fileNamer, IRepository repository) 
{ ... } 

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

, तो दूसरी ओर, यदि आप ऐसा करते ...

class DocumentCreator(IDependencyContainer container) 
{ ... } 

... आप निर्भरता छिप गए हैं। कक्षा के आंतरिक भाग की जांच किए बिना आप नहीं जानते, कि इसे आईफाइलनामर और आईरिपोजिटरी की आवश्यकता है।

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

Answer 2

मुझे लगता है कि इस दृष्टिकोण के साथ मुख्य समस्या यह है कि आप अब निर्भरताओं को स्पष्ट रूप से नहीं देखते हैं। एक और समस्या यह हो सकती है कि परीक्षण करना अधिक कठिन हो।

Answer 3

जो आप वर्णन करते हैं वह एक सेवा लोकेटर है। इसे आधुनिक अनुप्रयोग डिजाइन में एक विरोधी पैटर्न माना जाता है। This article क्यों बताता है।