सेवा लोकेटर बनाम निर्भरता इंजेक्शन

Question

मैं इस तरह के बयानों की एक बहुत कुछ के साथ कोड की समीक्षा कर रहा हूँ:

private SomeInterface x = Locator.getInstance(SomeInterface.class) 

मैं उम्मीद करेंगे

की तरह कुछ

private SomeInterface x; 

@Inject 
public Consumer(SomeInterface x){ // constructor 
    this.x = x; 
} 

वहाँ कुछ पहले दृष्टिकोण के साथ कुछ गलत है? ठीक है, निर्भरता इतनी स्पष्ट नहीं हैं, लेकिन लोकेटर की कॉन्फ़िगरेशन के माध्यम से कार्यान्वयन आसानी से बदला जा सकता है।

Answer 1

पहले उदाहरण: एक्स = Locator.getInstance (SomeInterface.class) है सेवा लोकेटर पैटर्न की तरह लग रहा है, और http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx जांच इस लेख में यह कहते सेवा लोकेटर एक विरोधी पैटर्न है और

और के लिए बचा जाना चाहिए दूसरा उपयोग यह सब ठीक है मैं कन्स्ट्रक्टर इंजेक्शन पसंद करता हूं, इसका चिकनी ठीक कार्यान्वयन। लेकिन मैं एट्रिब्यूट्स (जावा में एनोटानिटन्स) का उपयोग नहीं करना चाहूंगा क्योंकि कभी भी मैं डी कंटेनर को बदलना चाहता हूं जिसका उपयोग मैं कर रहा हूं और मैं सभी वर्गों से एक विशेषता को हटाना नहीं चाहता हूं।

Answer 2

मार्टिन Fowler लिखा एक article on DI versus Locators:

डि के लिए:

• आसान निर्धारित करने के लिए क्या एक घटक है निर्भरता - निर्माता को देखो।
• घटक सेवा लोकेटर पर निर्भरता नहीं है इसलिए समस्या नहीं है यदि घटक के साथ एक अलग ढांचे के साथ उपयोग किया जाता है।
• डि आसान परीक्षण कर सकता है, लेकिन एक अच्छा सेवा लोकेटर तंत्र मेकअप डि के खिलाफ समान रूप से संभव

छोटा करते देगा:

• कठिन डिबग करने के लिए और समझते हैं।
• कंपोनेंट कॉन्फ़िगर किए जाने के बाद इंजेक्टर से अतिरिक्त सेवाओं का अनुरोध नहीं कर सकता है।

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

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

Answer 3

सेवा लोकेटर पैटर्न के साथ इस तरह के रूप "गलत" कुछ भी नहीं है,

इस विशेष मामले में, डि के पक्ष में एक प्रमुख तर्क testability होगा।

बिना किसी संदेह के, DI बेहतर इकाई परीक्षण के लिए अनुमति देता है। लोकेटर पर स्थिर getInstance विधि अलगाव में परीक्षण करना अधिक कठिन बनाता है।

Answer 4

Service locator पैटर्न "सेवा लोकेटर" के रूप में जाना जाने वाला एक केंद्रीय रजिस्ट्री का उपयोग करता है जो अनुरोध पर एक निश्चित कार्य करने के लिए आवश्यक जानकारी देता है।

• हालात रजिस्ट्री में रखा जाता है के साथ प्रणाली के आराम करने के संबंध प्रभावी रूप से ब्लैक बॉक्स:

  ये सेवा लोकेटर डिजाइन पैटर्न का सबसे बुरा पहलू हैं। इससे पता लगाना मुश्किल हो जाता है और उनकी त्रुटियों से ठीक हो जाता है, और सिस्टम को कम विश्वसनीय बना सकता है।

• रजिस्ट्री अद्वितीय होना चाहिए, जो इसे
  समवर्ती अनुप्रयोगों के लिए एक बाधा बना सकता है।

• रजिस्ट्री एक गंभीर सुरक्षा भेद्यता हो सकती है, क्योंकि यह बाहरी लोगों को कोड को सीधे एप्लिकेशन में इंजेक्ट करने की अनुमति देता है।

• निर्माता द्वारा निर्भरता पारित नहीं कर सकते हैं इकाई परीक्षण

और करने के लिए और कड़ी (जैसा कि हम डि पैटर्न में करते हैं) मैं सेवा लोकेटर डिजाइन पद्धति का उपयोग कर मेरी राय केवल के शीर्ष स्तर पर स्वीकार्य है अपने एप्लिकेशन जब आपका सर्विस लोकेटर शायद