विरासत संहिता

Question

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

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

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

यदि मैं कोड कंप्लेक्स पर CommonServiceLocator लाइब्रेरी की तरह कुछ में अपने कंटेनर को लपेटता हूं, तो क्या यह एक उचित दृष्टिकोण होगा?

अन्य लोगों ने क्या किया है?

Answer 1

आप अपने विरासत कंटेनर से DI कंटेनर को छिपाने के लिए एक मुखौटा/प्रॉक्सी पैटर्न का उपयोग कर सकते हैं। आप अनिवार्य रूप से अपनी विरासत को एक कस्टम क्लास में कड़ी मेहनत कर रहे हैं जिसे आप कार्यान्वित करते हैं जो डी कंटेनर के बारे में जानेंगे। अब यदि आप अपने डीआई को संशोधित करते हैं तो आप अपने मुखौटे को अपने विरासत कोड को अपडेट नहीं करते हैं।

मैंने सामान्य सेवा लोकेटर में बहुत से शोध नहीं किए हैं, लेकिन यह आधार एक अच्छा समाधान हो सकता है। आप अपने मुखौटा को सीएसएल से जोड़ना चाहते हैं, यह आपके विरासत कोड से पूरी तरह से डी अवधारणा को छुपाएगा।

Answer 2

जैसा कि मैं आपका प्रश्न समझता हूं, आप लीगेसी कोड से डी-सक्षम कोड का आह्वान करना चाहते हैं।

सबसे अच्छा विकल्प नई लाइब्रेरी DI Friendly, but container-agnostic रखना है।

ऐसा करने से, आप विरासत कोड का उपयोग कर सकते हैं एक साधारण फेकाडे प्रदान कर सकते हैं। विरासत ऐप को किसी भी डी कंटेनर का उपयोग करने की आवश्यकता नहीं है, और सामान्य सेवा लोकेटर की आवश्यकता नहीं है।