जंजीर निर्माणकर्ताओं के साथ कोड विश्लेषण CA2000 चेतावनी से बचना?

मैं IDataRepository तर्क लेने वाले निर्माता पर CA2000 उल्लंघन को दोबारा नहीं कर सकता। इसे देखते हुए, इस तथ्य के साथ कि आप दोनों कंस्ट्रक्टरों के लिए समान "डिफ़ॉल्ट" का उपयोग करते हैं, नमूना परिदृश्य के लिए CA2000 समस्याओं से बचने वाला सबसे सरल परिवर्तन है:

public HomeController(IDataRepository db)
{
    this.repo = db ?? new SqlDataRepository();
}

public HomeController()
    : this(null)
{
}

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

public HomeController(IDataRepository db)
    : this(() => db, false)
{
    if (db == null)
    {
        throw new ArgumentNullException("db");
    }
}

public HomeController()
    : this(() => new SqlDataRepository(), true)
{
}

private HomeController(Func<IDataRepository> repositoryRetriever, bool disposeOnFailure)
{
    IDataRepository repository = repositoryRetriever.Invoke();
    try
    {
        this.repo = repository;
    }
    catch
    {
        if (disposeOnFailure)
        {
            repository.Dispose();
        }

        throw;
    }
}

व्यक्तिगत रूप से, मुझे लगता है कि उपरोक्त बहुत बुरा हैक है, विशेष रूप से यह देखते हुए कि इसमें संभावित समस्या से बचने के हितों में कोड जटिलता और रनटाइम अपवाद की संभावना दोनों को बढ़ाना शामिल है जो पहले स्थान पर बहुत गंभीर नहीं था। मेरी सिफारिश होगी कि इस प्रकार के संभावित CA2000 उल्लंघनों को केवल तब तक अनदेखा किया जाए जब तक कि निम्नलिखित दोनों सत्य न हों:

1. ऑब्जेक्ट की तात्कालिकता और उस विधि के अंत के बीच एक गैर-दुर्घटनाग्रस्त अपवाद का एक वास्तविक मौका है जिसमें इसे किसी फ़ील्ड को सौंपा गया है।
2. अनाथ उदाहरण को निपटाने में विफल रहने के परिणाम काफी गंभीर होते हैं (जैसे: किसी फ़ाइल को लॉक छोड़ना)।