डब्ल्यूसीएफ - एक अपवाद या फॉल्ट अपवाद फेंको?

Question

और अधिक कुशल क्या है? आप फेंक है,

1. एक अपवाद उत्पन्न हुई और पकड़ा जाता है कि मौजूदा Exception या एक नया FaultException बना सकते हैं और फेंक कि: एक अपवाद फेंकने या एक गलती फेंक ... जिस तरह से मैं इसे देखना 2 परिदृश्य है कि नहीं है?

2. आपका स्वयं का तर्क (जैसे उपयोगकर्ता नाम खाली नहीं हो सकता है) को एक अपवाद या FaultException के रूप में त्रुटि को फेंकने की आवश्यकता है। आप कौन सा चुनते हैं?

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

Answer 1

डब्ल्यूएसडीएल अनुबंध परिप्रेक्ष्य से आ रहा है, प्रत्येक ऑपरेशन में सबसे अधिक प्रतिक्रिया हो सकती है। हालांकि, आप कई गलती अनुबंधों को परिभाषित कर सकते हैं, जो मूल रूप से क्लाइंट को बताते हैं "DataContractX द्वारा परिभाषित प्रतिक्रिया या FaultContractY या FaultContractZ द्वारा परिभाषित गलती प्रतिक्रिया की अपेक्षा करें।"

FaultExceptions का उपयोग करके आप अपने डब्लूएसडीएल का प्रतिनिधित्व कैसे करते हैं (या पहले से परिभाषित डब्लूएसडीएल के खिलाफ एक अनुपालन सेवा लिखने पर) पर बेहतर नियंत्रण की अनुमति देता है।

यदि आप वास्तव में अंतःक्रियाशीलता प्राप्त करने का प्रयास कर रहे हैं और इसे प्राप्त करने के लिए wsdl और साबुन का पूरी तरह से लाभ उठा रहे हैं तो आपको FaultExceptions का उपयोग करने की आवश्यकता होगी। यदि आप .NET केवल इंटरैक्शन में डब्ल्यूसीएफ का उपयोग कर रहे हैं तो आप अपवाद या दोष अपवादों का उपयोग कर सकते हैं, मुझे नहीं लगता कि प्रदर्शन अंतर महत्वपूर्ण होगा (नेटवर्क पर संचार करना डब्ल्यूसीएफ रनटाइम रैपिंग की तुलना में अधिक महत्वपूर्ण है, जेनेरिक में अपवाद तार पर संचरण के लिए दोष)।

Answer 2

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

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

हैंडलिंग अपवाद हमेशा एक महंगी प्रक्रिया है लेकिन सेवा पक्ष पर FaultException या किसी अन्य .NET अपवाद को फेंकने के बीच कोई वास्तविक प्रदर्शन अंतर नहीं है।

Answer 3

मेरी समझ से यदि आप wsHttp बाइंडिंग का उपयोग कर रहे हैं और यदि आप FaultException के बजाय .NET अपवाद फेंकते हैं तो सर्वर-क्लाइंट चैनल दोषपूर्ण स्थिति में होगा, और प्रॉक्सी क्लास ऑब्जेक्ट को मौजूदा प्रॉक्सी ऑब्जेक्ट के रूप में पुनर्निर्मित करना होगा अनुपयोगी होगा। तो सबसे अच्छा अभ्यास FaultException का उपयोग करना हो सकता है।

Answer 4

आप बस 'अपवाद' का उपयोग करके अपवाद फेंक, तो WCF सेवा के पीछे FaultExceptionin बढ़ा देंगे और अपवाद के मूल कारण ग्राहक द्वारा कभी नहीं जाना जाएगा, जब तक आप web.config में <serviceDebug includeExceptionDetailInFaults="true"/> का उल्लेख है। यदि आप क्लाइंट को अपवाद के पीछे कारण/कस्टम संदेश जानना चाहते हैं, तो FaultException को प्राथमिकता दें।यह अजीब टाइप अपवाद रखने का सबसे अच्छा अभ्यास है।