2012-07-26 10 views
8

मेरे पास कुछ वैश्विक घटक हैं, मुझे यकीन नहीं है कि उन्हें डिज़ाइन में कैसे रखा जाए। जैसे:सेटर इंजेक्शन या परिवेश संदर्भ पैटर्न

  • सेटिंग्स वर्ग: यह कार्यक्रम के प्रारंभिक सेटिंग्स इंटरफ़ेस करता है, यह app.config जा सकता है (1way), web.config (1way), हार्ड कोडित मूल्यों (1way), या दृश्यों के पीछे sqldb (2way)।

  • भाषा वर्ग: यह अलग भाषा सेट शामिल है, और फिर, मैं इसके पीछे कुछ resx फ़ाइलें (1way), हार्ड कोडित मूल्यों (1way) या sqldb (2way) हो सकता था।

पहला सवाल, है मैं निर्भरता इंजेक्शन में इन कक्षाओं सेटर गुण (मैं विंडसर का उपयोग करें) बनाना चाहिए:

string DoSomethingAndReportIt() { 
    //do something ... 
    var param = Settings.Current.SomeParam; 
    //report it ... 
    return Language.Current.SomeClass_SomeMethod_Job_Done; 
} 

मैं:

public ISettings Settings {set;} 
public ILanguage Language {set;} 

या मैं उन्हें परिवेश संदर्भ बनाना चाहिए ध्यान दें कि .NET लाइब्रेरी में कुछ घटक हैं जो वास्तव में परिवेश संदर्भ पैटर्न का उपयोग करते हैं, उदाहरण के लिए System.Security.Principal, System.Web.ProfileBase, System.Thread.CurrentCulture ...

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

दूसरा प्रश्न यह है कि यदि डी बेहतर है, (मुझे लगता है कि डी पैटर्न को प्राथमिकता दी जाती है), सुरक्षा जैसे मौजूदा परिवेश वर्गों को प्रॉक्सी करने का एक अच्छा तरीका क्या है। प्रिंसिपल या प्रोफाइल डी पैटर्न का पालन करने के लिए?

उत्तर

3

परिवेश संदर्भ ठीक है जब आपको कई परतों में फैली कार्यक्षमता को कार्यान्वित करने की आवश्यकता होती है। (आपके मामले में आप कहते हैं कि दो वस्तुएं वैश्विक हैं) इस कार्यक्षमता को क्रॉसकटिंग चिंताओं के रूप में जाना जाता है। जैसा कि आपने देखा है .NET में कई वर्ग परिवेश संदर्भ, IPrincipal जैसे लागू किए गए हैं। परिवेश संदर्भ के कार्यान्वयन के एक कार्यशील संस्करण को प्राप्त करने के लिए, आपको अपने Settings और Language ऑब्जेक्ट्स को प्रदान किए गए कुछ डिफ़ॉल्ट मान होने की आवश्यकता होगी यदि वे परिवेश संदर्भ के रूप में विकसित किए गए हैं। मेरी धारणा यह है कि आप ILanguage और ISettings के कुछ डिफ़ॉल्ट कार्यान्वयन प्रदान करेंगे, और इस बात पर विचार करते हुए कि आप वैश्विक स्तर पर उनका उपयोग करेंगे वे परिवेश संदर्भ के लिए अच्छे उम्मीदवार हैं।

दूसरी तरफ, आप इन दो इंटरफेस को लागू करने वाली वस्तुओं का उपयोग करने की कितनी बार योजना बनाते हैं? और, दो वस्तुओं का अस्तित्व महत्वपूर्ण है, जिसका अर्थ Settings != null और Language != null है? यदि आप वास्तव में उन्हें एक या दो कक्षाओं में उपयोग करना चाहते हैं, और/या यदि वस्तुओं का अस्तित्व वास्तव में महत्वपूर्ण नहीं है, तो आप सेटर इंजेक्शन के साथ जाना चाहेंगे। सेटर इंजेक्शन को वास्तव में डिफ़ॉल्ट मान की आवश्यकता नहीं है, इसलिए आपकी ऑब्जेक्ट null हो सकती है।

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

+0

आपको परिवेश संदर्भ क्यों पसंद नहीं है? – Ziv

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

  • कोई संबंधित समस्या नहीं^_^