2011-06-24 16 views
6

में अपवादों के अंतिम उपयोगकर्ता को सूचित करना Winforms-MVP के आधा साल के दौरान मैंने निम्नलिखित अपवाद हैंडलिंग रणनीति तैयार की है। मेरे पास इनपुट पैरामीटर (हस्ताक्षर अलग-अलग) के रूप में एक प्रतिनिधि को लेकर कई निष्पादन विधियों के साथ मूल सार प्रस्तुतकर्ता वर्ग है। व्यू और प्रेजेंटर के बीच बातचीत IView में परिभाषित घटनाओं (इनपुट) के माध्यम से और सार्वजनिक गुण (आउटपुट) या IView में परिभाषित कॉलिंग विधियों को सेट करके और दृश्य द्वारा कार्यान्वित करके किया जाता है। प्रस्तुतकर्ता में प्रत्येक इवेंट हैंडलर ठोस निष्पादन के साथ प्रदान करने वाले निष्पादन विधियों में से एक को कॉल करता है।Winforms-MVP और WPF-MVVM

मैं बहुत निश्चित अपवाद है कि हो सकता के लिए कई कैच ब्लॉक है विधि पर अमल में (जिसका मुख्य कारण है कि व्यापक रूप से इस्तेमाल कर रहे हैं बाहरी घटकों में कुछ समस्याओं का)। इन अपवादों में से प्रत्येक मौजूदा ऑपरेशन के निष्पादन को रोकता है, लॉग इन किया जा रहा है और उपयोगकर्ता को व्यू के तरीकों को कॉल करके सार्थक स्पष्टीकरण के साथ दिखाया गया है।

कुछ ही समय पहले (बहुत नहीं बहुत पहले वास्तव में) मैं WPF-MVVM सीखने पहली नज़र से एमवीपी के साथ आम में ज्यादा लगता है जो शुरू कर दिया। मैं वहां अपवाद हैंडलिंग रणनीति से संबंधित कुछ आसान सलाह ढूंढ रहा था (मुख्य रूप से उपयोगकर्ताओं को समस्याओं के बारे में सूचित करना), लेकिन सामान्य रूप से इन प्रश्नों को खोजना मुश्किल है - मेरा मतलब है, बहुत कुछ कहा जाता है, लेकिन मुख्य रूप से सिद्धांत में। मुझे app.xaml.cs में "हैंडलिंग" अनचाहे अपवादों के 20 से अधिक उदाहरण मिल गए हैं, यह सब बहुत अच्छा है, लेकिन मुझे ईमानदारी से बताएं - अगर आपको सटीक अपवाद पता हैं जो आपको ऐप को क्रैश कर सकता है, तो क्या आप उन्हें संभाल नहीं पाएंगे थोड़ा पहले (भले ही आपको अपना ऐप बंद करने के लिए मजबूर किया जाएगा)? मैं सभी संभावित अपवादों को पकड़ने का कोई प्रशंसक नहीं हूं। नेटवर्क समस्याओं, अस्थायी डेटाबेस अनुपलब्धता के कारण बहुत से अपवाद हैं और इतने पर बिना किसी डरावनी त्रुटि आइकन के आवेदन को बंद किए बिना संभाला जाना चाहिए, जिससे सामान्य उपयोगकर्ता को अपना अनुरोध दोहराने का मौका मिलता है।

तो एक प्रयोग के रूप मैं लगभग एक ही बात करने की कोशिश की, जैसा कि मैंने पहले वर्णित - अपवाद संक्रमण के लिए ViewModel में मेरे द्वारा बनाए गए घटनाओं और उन्हें देखें सदस्यता ली। लेकिन, स्पष्ट रूप से बोलते हुए, इस तरह से मुझे रेंगने देता है।

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

+0

आप किस हिस्से से चिंतित हैं? जल्दी पकड़ना, या देर से पकड़ना? यदि आपने जल्दी पकड़ नहीं लिया है, तो क्या आपको लगता है कि इसका डब्ल्यूपीएफ/एमवीवीएम के साथ कुछ लेना देना है? –

उत्तर

6

हमारे डब्ल्यूपीएफ ऐप्स में विभिन्न प्रकार की त्रुटि स्थितियों के लिए हमारे पास कुछ अलग-अलग रणनीतियों हैं।

अनुमानित त्रुटियों के लिए कोड उपयोगकर्ता को सूचित किए बिना संभाल सकता है और आगे बढ़ सकता है, हम सामान्य प्रयास कैच ब्लॉक करते हैं।

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

त्रुटियों के लिए हमें उम्मीद नहीं है कि हम पूर्ण विवरण प्राप्त करने के लिए Red Gate SmartAssembly का उपयोग करें ताकि उपयोगकर्ता उन्हें विश्लेषण के लिए हमारे समर्थन में भेज सकें। हमारा विचार यह है कि अपवादों के बाद आपके ऐप को पकड़ना और जारी रखना, जिसे आपने अनुमानित नहीं किया है, एक बहुत ही जोखिम भरा रणनीति है - एक अप्रत्याशित अपवाद से ढेर अवांछित नहीं है और त्रुटि के बाद आपका ऐप असंगत स्थिति में छोड़ा जाएगा (जिसके परिणामस्वरूप डेटा को भ्रष्ट करने के लिए एक अजीब यूआई से कुछ भी) और साइड इफेक्ट्स हो सकते हैं जो अनुमान लगाने के लिए असंभव हैं। ऐप क्रैश होने के लिए यह एक अच्छा उपयोगकर्ता अनुभव नहीं है, लेकिन ऐप द्वारा अनदेखा की गई त्रुटि के कारण एक अप्रत्याशित स्थिति के कारण यह भ्रष्ट डेटा होने का एक बहुत ही खराब अनुभव है। हमारी रणनीति दुर्घटना के बारे में ज्यादा जानकारी हासिल करने के लिए है ताकि उपयोगकर्ता जानता है कि हम समस्या को हल करने के बारे में गंभीर हैं और हम संभावित रूप से खराब समस्याओं के लिए आगे बढ़ने और आगे बढ़ने के बजाय भविष्य में अपडेट में इसे फिक्स्ड/पकड़े जाएंगे।

+0

अधिक विशिष्ट जानकारी के लिए सारांश के साथ अच्छी संक्षिप्त व्याख्या। –

+0

+1 जितना संभव हो उतना अपवाद संभालने के लिए और जिन पर आप स्पष्ट रूप से अपेक्षा नहीं करते थे उन पर दुर्घटनाग्रस्त हो जाएगा और उन लोगों को "संभालने" के लिए एक प्रणाली होगी – Marijn

1

मैं सहमत हूं कि आपके app.xaml.cs में अपवादों को संभालने से अच्छा नहीं है, क्योंकि यह मूल रूप से बहुत देर हो चुकी है!

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

  1. त्रुटियों कि कुछ लंबे समय से चल समस्या का संकेत के लिए, नेटवर्क समस्याओं उदाहरण के लिए, मैं एक 'ErrorState' poperty
  2. क्षणिक मुद्दों के लिए बेनकाब, फ़ाइल नहीं मिला उदाहरण के लिए, एक घटना का पर्दाफाश करें।
संबंधित मुद्दे