2010-06-10 19 views
6

यह पता लगाने की कैसे सबसे अच्छा इस परिदृश्य को संभालने के लिए कोशिश कर रहा है:निर्भरता इंजेक्शन और कारखाने

public class RequestContext : IRequestContext 
{ 
    private readonly ServiceFactory<IWeatherService> _weatherService; 

    public RequestContext(ServiceFactory<IWeatherService> weatherService, UserLocation location, string query) 
    { 
     _weatherService = weatherService; 
     ... 

निर्भरता किस तरह की:

जैसे एक RequestContext वर्ग है जो एक बाहरी सेवा से निर्भरता है, मान लें क्या मुझे कक्षा में आवश्यकता होनी चाहिए जो आखिरकार RequestContext को तुरंत चालू करेगी? यह ServiceFactory<IWeatherService> हो सकता है, लेकिन यह सही नहीं लगता नहीं है, या मैं की तर्ज पर इसके लिए एक IRequestContextFactory बना सकते हैं:

public class RequestContextFactory : IRequestContextFactory 
{ 
    private readonly ServiceFactory<IWeatherService> _weatherService; 

    public RequestContextFactory(ServiceFactory<IWeatherService> weatherService) 
    { 
     _weatherService = weatherService; 
    } 

    public RequestContext Create(UserLocation location, string query) 
    { 
     return new RequestContext(_weatherService, location, query); 
    } 
} 

और फिर निर्माता इंजेक्शन के माध्यम से IRequestContextFactory गुजरती हैं।

यह ऐसा करने का एक अच्छा तरीका प्रतीत होता है, लेकिन इस दृष्टिकोण के साथ समस्या यह है कि मुझे लगता है कि यह खोज में बाधा डालता है (देवताओं को कारखाने के बारे में पता होना चाहिए और इसे लागू करना चाहिए, जो वास्तव में स्पष्ट नहीं है)।

क्या कोई बेहतर/अधिक खोजने योग्य तरीका है जिसे मैं याद कर रहा हूं?

उत्तर

5

ढीले युग्मन की सुंदरता यह है कि हम लगातार पिछले विवरण को छिपा सकते हैं।

IRequestContext के उपभोक्ता के परिप्रेक्ष्य से RequestContext का अस्तित्व और इसकी निर्भरता पूरी तरह से कार्यान्वयन विवरण है। केवल आवेदन के Composition Root पर

public class MyClass 
{ 
    private readonly IRequestContext reqCtx; 

    public MyClass(IRequestContext reqCtx) 
    { 
     if (reqCtx == null) 
     { 
      throw new ArgumentNullException("reqCtx"); 
     } 

     this.reqCtx = reqCtx; 
    } 

    // Implement using this.reqCtx... 
} 

तुम सब कुछ एक साथ अंत में तार करने की आवश्यकता है: Liskov Substitution Principle की वजह से, उपभोक्ता केवल IRequestContext के साथ सौदा करना चाहिए। यहां एक गरीब मैन के डी दृष्टिकोण का एक स्केच है:

ServiceFactory<IWeatherService> weatherService = 
    new ServiceFactory<IWeatherService>(); 
UserLocation location = new UserLocation; 
string query = "foo"; 

IRequestContext reqCtx = new RequestContext(weatherService, location, query); 

var mc = new MyClass(reqCtx); 
+0

दिलचस्प, मैंने सीधे अनुरोध कॉन्टेक्स्ट इंजेक्शन के बारे में नहीं सोचा है क्योंकि इसके पैरामीटर प्रत्येक पृष्ठ अनुरोध (एएसपी.नेट एमवीसी) पर भिन्न होंगे। क्या उदाहरण के लिए क्वेरी स्ट्रिंग में देखकर मेरे लिए कक्षा को ठीक से चालू करने के लिए एन इंजेक्ट का उपयोग करना अच्छा विचार होगा? या क्या मैं एक इंजेक्शन को एक कारखाने का उपयोग करने के लिए कॉन्फ़िगर करता हूं जो एक उदाहरण देता है, लेकिन मूल स्तर पर केवल RequestContext इंजेक्ट करता है? – andreialecu

+0

मुझे अभी तक इस बारे में विनिर्देशों का उत्तर देने के लिए पर्याप्त रूप से निनजेक नहीं पता है, लेकिन यदि यह सीधे इसका समर्थन नहीं करता है, तो आप उच्च स्तर के उपभोक्ता में इंजेक्शन वाली सार फैक्ट्री का उपयोग करके हमेशा इस छोटे हिस्से को अपने आप कार्यान्वित कर सकते हैं। "प्रदाता" प्रत्यय के लिए –

0

फैक्टरी पैटर्न एक प्रसिद्ध, प्रलेखित और उपयोग की गई विधि है। यदि आप अन्य देवताओं के बारे में चिंतित हैं जो गति से नहीं हैं, तो कोड में (xml) दस्तावेज़ में wikipedia's factory pattern page पर एक लिंक डालें।

इसके अलावा, सुनिश्चित करें कि आप अपने कारखानों को ध्यान से नाम दें - माइक्रोसॉफ्ट प्रदाता प्रत्यय की तरह प्रतीत होता है।

+0

+1। मेरे कारखानों को दोबारा करने की जरूरत है। :) 'प्रदाता' के लिए – andreialecu

+1

-1। क्या आप जानते हैं _why_ वे 'प्रदाता' प्रत्यय हैं? इसे अंधाधुंध न करें क्योंकि एमएस इसका उपयोग करता है। यह एक पूरी तरह से अलग कारण के लिए हो सकता है। –

+4

http://msdn.microsoft.com/en-us/library/ms972319.aspx इंगित करता है कि वे प्रदाता का उपयोग करने वाले वर्ग को इंगित करने के लिए प्रदाता का उपयोग करते हैं जो ASP.NET प्रदाता मॉडल का उपयोग करता है। केवल उन परिस्थितियों में प्रदाता प्रत्यय उचित होगा। –

संबंधित मुद्दे