हाल ही में मैंने मार्क सेमन के लेख को सर्विस लोकेटर विरोधी पैटर्न के बारे में पढ़ा है ।
लेखक दो मुख्य कारणों के बारे में बताता है कि ServiceLocator एक प्रतिमान क्यों है:
एपीआई उपयोग की समस्या (जो कि मैं पूरी तरह से ठीक हूं)
जब क्लास एक सेवा लोकेटर को नियुक्त करती है तो इसकी निर्भरता को देखना बहुत कठिन होता है, ज्यादातर मामलों में, क्लास में केवल एक PARAMETERLESS कंस्ट्रक्टर होता है। ServiceLocator के विपरीत, DI दृष्टिकोण स्पष्ट रूप से निर्माणकर्ता के मापदंडों के माध्यम से निर्भरता को उजागर करता है, ताकि इंटेलीजेंसी में निर्भरता आसान दिखाई दे।रखरखाव का मुद्दा (जो मुझे पहेलियाँ)
निम्नलिखित विस्तार पर विचार करें
हमारे पास एक वर्ग 'MyType' है जो सेवा लोकेटर दृष्टिकोण को नियोजित करता है:
public class MyType
{
public void MyMethod()
{
var dep1 = Locator.Resolve<IDep1>();
dep1.DoSomething();
}
}
अब हम 'MyType' श्रेणी में एक और निर्भरता जोड़ना चाहते हैं
public class MyType
{
public void MyMethod()
{
var dep1 = Locator.Resolve<IDep1>();
dep1.DoSomething();
// new dependency
var dep2 = Locator.Resolve<IDep2>();
dep2.DoSomething();
}
}
और यहीं से मेरी गलतफहमी शुरू होती है। लेखक कहता है:
यह बताना बहुत कठिन हो जाता है कि आप एक परिवर्तन को शुरू कर रहे हैं या नहीं। आपको पूरे एप्लिकेशन को समझने की आवश्यकता है जिसमें सर्विस लोकेटर का उपयोग किया जा रहा है, और कंपाइलर आपकी मदद करने वाला नहीं है।
लेकिन एक सेकंड रुको, अगर हम DI दृष्टिकोण का उपयोग कर रहे थे, तो हम कंस्ट्रक्टर में एक अन्य पैरामीटर के साथ निर्भरता का परिचय देंगे (निर्माण इंजेक्शन के मामले में)। और समस्या तब भी रहेगी। यदि हम ServiceLocator को सेटअप करना भूल सकते हैं, तो हम अपने IoC कंटेनर में नया मैपिंग जोड़ना भूल सकते हैं और DI दृष्टिकोण से समान रन-टाइम समस्या होगी।
इसके अलावा, लेखक ने इकाई परीक्षण कठिनाइयों के बारे में उल्लेख किया है। लेकिन, क्या हमारे पास DI दृष्टिकोण के साथ कोई समस्या नहीं है? क्या हमें उन सभी परीक्षणों को अद्यतन करने की आवश्यकता नहीं है जो उस वर्ग को त्वरित कर रहे थे? हम उन्हें केवल हमारे परीक्षण को अनिवार्य बनाने के लिए एक नए नकली निर्भरता को पारित करने के लिए अद्यतन करेंगे। और मुझे उस अपडेट और समय बिताने से कोई लाभ नहीं दिखता है।
मैं सेवा लोकेटर दृष्टिकोण का बचाव करने की कोशिश नहीं कर रहा हूं। लेकिन इस गलतफहमी से मुझे लगता है कि मैं बहुत महत्वपूर्ण कुछ खो रहा हूं। क्या कोई मेरा संदेह दूर कर सकता है?
अद्यतन (सारांश):
मेरे सवाल का जवाब "क्या सेवा लोकेटर एक विरोधी पैटर्न है" वास्तव में परिस्थितियों पर निर्भर करता है। और मैं निश्चित रूप से इसे आपके टूल लिस्ट से पार करने का सुझाव नहीं दूंगा। जब आप विरासत कोड के साथ काम करना शुरू करते हैं तो यह बहुत उपयोगी हो सकता है। यदि आप अपनी परियोजना के बहुत शुरुआत में भाग्यशाली हैं तो DI दृष्टिकोण एक बेहतर विकल्प हो सकता है क्योंकि इसमें सेवा लोकेटर पर कुछ फायदे हैं।
और यहाँ मुख्य अंतर हैं जिन्होंने मुझे अपनी नई परियोजनाओं के लिए सेवा लोकेटर का उपयोग नहीं करने के लिए आश्वस्त किया:
- सबसे स्पष्ट और महत्वपूर्ण: सेवा लोकेटर वर्ग निर्भरता को छुपाता है
- यदि आप कुछ IoC कंटेनर का उपयोग कर रहे हैं, तो यह सभी आश्रितों को मान्य करने और लापता मैपिंग (या गलत कॉन्फ़िगरेशन) पर तत्काल प्रतिक्रिया देने के लिए स्टार्टअप पर सभी कंस्ट्रक्टर को स्कैन करने की संभावना रखेगा; यदि आप अपने IoC कंटेनर को सेवा लोकेटर के रूप में उपयोग कर रहे हैं तो यह संभव नहीं है
विवरण के लिए उत्कृष्ट उत्तर पढ़ें जो नीचे दिए गए हैं।