c# - आप कॉमन सर्विस लोकेटर का उपयोग कब करेंगे?




dependency-injection inversion-of-control (3)

कल्पना कीजिए कि आप तीसरे पक्ष के डेवलपर्स द्वारा उपयोग किए जाने के लिए लाइब्रेरी कोड लिख रहे हैं। आपका कोड सेवा की उन वस्तुओं को बनाने में सक्षम होना चाहिए जो ये डेवलपर्स प्रदान करते हैं। हालाँकि आपको पता नहीं है कि आपके प्रत्येक कॉलर में कौन सा IoC कंटेनर इस्तेमाल होगा।

कॉमन सर्विस लोकेटर आपको अपने उपयोगकर्ताओं पर दिए गए IoC को मजबूर किए बिना ऊपर से सामना करने देता है।

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

मैं कॉमन सर्विस लोकेटर को अपने आईओसी कंटेनर को अमूर्त करने के एक तरीके के रूप में देख रहा हूं लेकिन मैं यह देख रहा हूं कि कुछ लोग इस प्रकार के खिलाफ हैं।

क्या लोग इसका इस्तेमाल नहीं करने की सलाह देते हैं? हमेशा इसका उपयोग? या कभी-कभी इसका उपयोग करते हुए? यदि कभी-कभी, तो आप किन स्थितियों में इसका उपयोग करेंगे और किन स्थितियों में आप इसका उपयोग नहीं करेंगे।


मैंने देखा कि CSL का उपयोग करने के खिलाफ एक तर्क एक मिथ्या है, क्योंकि डेवलपर्स को लगता है कि यह लाइब्रेरी केवल सेवा लोकेटर पैटर्न करने में सक्षम है। हालांकि ऐसा नहीं है, क्योंकि डिपेंडेंसी इंजेक्शन पैटर्न के साथ भी इसका इस्तेमाल करना आसान है।

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

हालाँकि, फ्रेमवर्क डिज़ाइनर के रूप में, CSL पर निर्भरता को हल्के में नहीं लेना चाहिए। आपके ढांचे की प्रयोज्यता के लिए, आपके डीआई तंत्र का होना बेहतर है। एक बहुत ही सामान्य तंत्र कॉन्फ़िगरेशन फ़ाइल में निर्भरता स्थापित करना है। यह पैटर्न पूरे .NET फ्रेमवर्क में उपयोग किया जाता है। लगभग हर निर्भरता को दूसरे के लिए बदला जा सकता है। .NET प्रदाता पैटर्न इसके ऊपर बनाया गया है।

जब आप एक रूपरेखा डिजाइनर के रूप में, सीएसएल पर निर्भरता लेते हैं, तो उपयोगकर्ताओं के लिए आपके आवेदन का उपयोग करना कठिन होगा। उपयोगकर्ताओं को एक IoC कंटेनर को कॉन्फ़िगर करना होगा और इसे CSL तक हुक करना होगा। हालाँकि, यह कॉन्फ़िगरेशन के लिए मान्य करने के लिए संभव नहीं है। जैसा कि .NET कॉन्फ़िगरेशन सिस्टम का उपयोग करते समय किया जा सकता है, जो इसमें सभी प्रकार के सत्यापन का समर्थन करता है।


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





common-service-locator