वापसी मूल्यों के साथ त्रुटियों को शामिल करने के लिए डिज़ाइन पैटर्न

Question

मैं अपने एपीआई के माध्यम से सॉफ्टवेयर के दूसरे टुकड़े के लिए एक ऐड-इन लिख रहा हूं। एपीआई द्वारा लौटाई गई कक्षाएं केवल मूल सॉफ्टवेयर और एपीआई के माध्यम से पहुंच सकती हैं। इसलिए मैं अपने स्वयं के स्टैंड अकेले पीओसीओ/डीटीओ ऑब्जेक्ट्स लिख रहा हूं जो एपीआई कक्षाओं में मैप करते हैं। मैं एक ऐसी सुविधा पर काम कर रहा हूं जो मूल फ़ाइल में पढ़ेगा, और इन पॉको ऑब्जेक्ट्स का संग्रह वापस कर देगा जिन्हें मैं कहीं और चुरा सकता हूं। वर्तमान में मैं JSON.NET का उपयोग कर रहा हूं ताकि इन वर्गों को जेएसओएन में क्रमबद्ध किया जा सके।

उदाहरण के लिए मैं अपने डीटीओ में देशी "व्यक्तियों" को पढ़ने के लिए इस

public class MyPersonDTO 
{ 
    public string Name {get; set;} 
    public string Age {get; set;} 
    public string Address {get; set;}  
} 

..और इस तरह की एक विधि की तरह एक डीटीओ हो सकता है वस्तुओं

public static class MyDocReader 
{ 
    public static IList<MyPersonDTO> GetPersons(NativeDocument doc) 
    { 
     //Code to read Persons from doc and return MyPersonDTOs 
    } 
} 

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

वर्तमान में जब कुछ "असाधारण" होता है तो मैं अपवाद लॉग करता हूं और निर्यात विफल रहता है। लेकिन मैंने फैसला किया है कि मैं जो भी कर सकता हूं उसे निर्यात करना चाहता हूं, और त्रुटियों को कहीं रिकॉर्ड कर सकता हूं।

सबसे आसान विकल्प सिर्फ अपवादों को लॉग और निगलना होगा और मैं जो कर सकता हूं उसे वापस करूँगा, हालांकि तब कोई समस्या होने पर मेरे कॉलिंग कोड को जानने का कोई तरीका नहीं होगा।

एक विकल्प जो मैं विचार कर रहा हूं वह एक अलग आउट पैरामीटर के रूप में त्रुटियों का शब्दकोश लौटा रहा है। कुंजी उस संपत्ति की पहचान करेगी जिसे पढ़ा नहीं जा सका, और मूल्य में अपवाद/त्रुटि का विवरण होगा।

public static class MyDocReader 
{ 
    public static IList<MyPersonDTO> persons GetPersons(NativeDocument doc, out IDictionary<string, string> errors) 
    { 
     //Code to read persons from doc 
    } 
} 

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

public class MyPersonDTO 
{ 
    public string Name {get; set;} 
    public string Age {get; set;} 
    public string Address {get; set;} 

    public IDictionary<string, string> Errors {get; set;} 
} 

यह आमतौर पर कैसे संभाला जाता है? क्या उन त्रुटियों की रिपोर्ट करने के लिए त्रुटियों की रिपोर्ट करने का कोई और विकल्प है जिन पर मैं विचार नहीं कर रहा हूं?

Answer 1

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

इस का लाभ यह है कि संस्थाओं साफ हो रहा है

नकारात्मक पक्ष यह है कि यह त्रुटियों को ठेस संस्थाओं/विशेषताओं के लिए वापस मैप करने के लिए कठिन हो जाएगा।

इकाइयों के बैच भेजते समय यह नकारात्मक समस्या एक बड़ी समस्या हो सकती है। जब एपीआई अधिक एकल इकाई उन्मुख होती है तो इससे कोई फर्क नहीं पड़ता।

Answer 2

प्रिंसिपल में, अगर एपीआई में कुछ गलत हो जाता है (जिसे पुनर्प्राप्त नहीं किया जा सकता है), तो कॉलिंग कोड को पता होना चाहिए कि एक अपवाद हुआ है। तो इससे निपटने के लिए इसमें एक रणनीति हो सकती है।

वजह, दृष्टिकोण है कि मेरे दिमाग में एक ही दर्शन से प्रभावित है की बात आती है -

1> परिभाषित अपने खुद के अपवाद कहना IncompleteReadException देता है। अपवाद होने तक रिकॉर्ड को संग्रहीत करने के लिए इस अपवाद में IList<MyPersonDTO> संपत्ति होगी।

public class IncompleteReadException : Exception 
{ 
    IList<MyPersonDTO> RecordsRead { get; private set; }  

    public IncompleteReadException(string message, IList<MyPersonDTO> recordsRead, Exception innerException) : base(message,innerException) 
    { 
     this.RecordsRead = recordsRead; 
    } 
} 

2> एक अपवाद तब होता है जब, जबकि पढ़ने, आप मूल अपवाद, पकड़ कर सकते हैं यह एक & फेंक IncompleteReadException

यह बुला कोड (अनुप्रयोग कोड) की अनुमति देगा में मूल अपवाद लपेट, के लिए अपूर्ण डेटा पढ़ने पर स्थिति से निपटने के लिए एक रणनीति है।