निर्भरता इंजेक्शन और लॉगिंग इंटरफेस

Question

मैं सोच रहा था कि कुछ सर्वोत्तम प्रथाओं को लॉगिंग और फ्रेमवर्क और निर्भरता इंजेक्शन लॉगिंग के आसपास क्या था। विशेष रूप से, यदि मैं एक कक्षा को डिजाइन कर रहा हूं जिसके लिए लॉग इन करने की आवश्यकता है, तो मुझे निर्भरता इंजेक्शन को ध्यान में रखने के लिए लॉग इन करने के लिए इंटरफ़ेस प्राप्त करने के बारे में कैसे जाना चाहिए?

निर्भरता इंजेक्शन यह कहता है कि बाहरी निर्भरताओं को बाहरी (कन्स्ट्रक्टर या प्रॉपर्टी सेटर्स) से इंजेक्शन दिया जाना चाहिए, तो क्या मुझे कन्स्ट्रक्टर में आईएलओजी इंस्टेंस लेना चाहिए और कक्षा में उपयोग करना चाहिए? क्या मुझे वैकल्पिक निर्भरता लॉगिंग करने और इसे एक सेटटर में प्राप्त करने पर विचार करना चाहिए? क्या मैं लॉगिंग इंटरफ़ेस को बदलने की अनुमति देकर बहुत अधिक लचीलापन के लिए दबाव डाल रहा हूं और क्या मुझे एक विशिष्ट लॉगिंग इंटरफ़ेस पर हार्ड निर्भरता लेनी चाहिए (उदाहरण के लिए एक फैक्ट्री विधि में कॉल के माध्यम से एक स्थिर आईएलओजी वैरिएबल बनाएं)? क्या यह फैक्ट्री विधि आईएलओजी कार्यान्वयन प्राप्त करने के लिए कंटेनर में कॉल कर सकती है या क्या यह प्रारंभिक होने वाले स्थिर चर के बीच प्रारंभिक संघर्ष और आईओसी कंटेनर शुरू किया जा रहा है?

मैं यह कर जाना चाहिए:

public class MyService : ISomeService 
{ 
    private static readonly ILogger s_log = 
      LoggingFactory.GetLogger(typeof(MyService)) 
    ... 
} 

या शायद यह:

public class MyService : ISomeService 
{ 
    protected virtual ILogger Logger {get; private set;} 
    public MyService(ILogger logger, [other dependencies]) 
    { 
    Logger = logger; 
    } 
} 

या यहाँ तक कि इस:

public class MyService : ISomeService 
{ 
    public virtual ILogger Logger {get; set;} 
    public MyService() 
    { 
    } 
} 

अन्य पैटर्न या तरीके यह करने के लिए? वहां क्या लोग हैं? क्या काम कर रहा है और कब?

Answer 1

यह बहुत अच्छा है कि आप उलटा नियंत्रण और निर्भरता-इंजेक्शन में देख रहे हैं।

लेकिन आपके प्रश्न के लिए, एक और अवधारणा है जिसे आप देखना चाहते हैं: पहलू उन्मुख प्रोग्रामिंग।

.NET में, कैसल, लिनफू और माइक्रोसॉफ्ट की नीति-इंजेक्शन एप्लिकेशन ब्लॉक सहित पहलू उन्मुख प्रोग्रामिंग करने के लिए कुछ अच्छे ढांचे उपलब्ध हैं। वास्तव में, कुछ उलटा नियंत्रण कंटेनरों में भी कुछ पहलू उन्मुख विशेषताएं हैं।

ये अवधारणाएं और औजार लॉगिंग जैसे चिंताओं को कोड शोर के संदर्भ में पृष्ठभूमि सीट लेने में मदद करते हैं, और स्वचालित रूप से संभाले जाते हैं।

Answer 2

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

Answer 3

मैं इसे इंजेक्शन और इंटरफ़ेस का उपयोग करने के लिए चिपकना चाहता हूं। मुख्य रूप से परीक्षण की सुविधा के लिए। खपत वस्तु का परीक्षण करते समय इसे नकली या स्टब को प्रतिस्थापित करना आसान होता है।

मैं आधार रखूंगा कि क्या मैं उपभोग करने वाले वर्ग के लॉग के महत्व पर कन्स्ट्रक्टर या सेटर इंजेक्शन का उपयोग करता हूं। यदि आप इसे महत्वपूर्ण बनाना चाहते हैं तो वैकल्पिक रूप से सेटटर के बाद, मैं कन्स्ट्रक्टर इंजेक्शन का पक्ष लेगा।

मुझे नहीं लगता कि कारखाने विधि का उपयोग करने वाले कंटेनर के साथ काम नहीं कर सका, हालांकि, यह उपभोक्ता वर्ग को इस फैक्ट्री विधि की उचित कॉन्फ़िगरेशन पर निर्भर करता है।

Answer 4

मेरी सलाह? लॉगिंग इंटरफेस को अपने आप में लपेटें।मैंने लॉग 4नेट पर एक बार निर्भरता ली, जला दिया और इसके कारण मेरी कई परियोजनाओं को दोबारा प्रतिक्रिया देना पड़ा।