2008-09-17 11 views
37

वर्तमान में हम बहस कर रहे हैं कि क्या डब्लूसीएफ चैनल पर दोषों को फेंकना बेहतर है या नहीं, एक संदेश से स्थिति या प्रतिक्रिया का संकेत देने वाला संदेश गुजर रहा है।डब्ल्यूसीएफ - दोष/अपवाद बनाम संदेश

दोष डब्लूसीएफ से अंतर्निहित समर्थन के साथ आते हैं जहां आप अंतर्निहित त्रुटि हैंडलर का उपयोग कर सकते हैं और तदनुसार प्रतिक्रिया दे सकते हैं। हालांकि, यह ओवरहेड लेता है क्योंकि .NET में अपवाद फेंकना काफी महंगा हो सकता है।

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

हम एक सामान्य संदेश वस्तु हम अपनी सेवाओं में प्रयोग कर सकते हैं बनाने में एक चाकू ले लिया, और यह है कि क्या हम साथ आया है:

public class ReturnItemDTO<T> 
{ 
    [DataMember] 
    public bool Success { get; set; } 

    [DataMember] 
    public string ErrorMessage { get; set; } 

    [DataMember] 
    public T Item { get; set; } 
} 

सब मेरी सेवा कॉल इस आइटम वापस, मैं लगातार जांच कर सकते हैं "सफलता" संपत्ति यह निर्धारित करने के लिए कि क्या सब ठीक हो गया है। मेरे पास घटना में एक त्रुटि संदेश स्ट्रिंग है जो इंगित करती है कि कुछ गलत हो गया है, और यदि आवश्यक हो तो एक सामान्य आइटम जिसमें डीटीओ होता है।

अपवाद जानकारी को केंद्रीय लॉगिंग सेवा में लॉग इन करना होगा और सेवा से वापस नहीं भेजा जाना चाहिए।

विचार? टिप्पणियाँ? विचार? सुझाव?

कुछ आगे स्पष्टीकरण मेरे सवाल पर

एक मुद्दा मैं आ रही गलती अनुबंध के साथ व्यापार के नियम संचार कर रहा है।

पसंद है, अगर कोई लॉग इन करता है, और उनका खाता लॉक है, तो मैं इसे कैसे संवाद करूं? उनका लॉगिन स्पष्ट रूप से विफल रहता है, लेकिन यह "खाता लॉक" कारण के कारण विफल रहता है।

तो मैं कार्य करें:

ए) एक बूलियन उपयोग करते हैं, संदेश खाते के साथ दोष फेंक बंद कर दिया

बी) प्रासंगिक जानकारी

उत्तर

31

हालांकि यह में अपवाद फेंकने के रूप में भूमि के ऊपर किया जाता है के साथ AuthenticatedDTO लौट आते हैं। नेट काफी महंगा हो सकता है।

आप एक्सएमएल के लिए ऑब्जेक्ट्स को क्रमबद्ध और डी-सीरियलाइज कर रहे हैं और उन्हें धीमे नेटवर्क पर भेज रहे हैं .. अपवाद फेंकने से उपरिवर्तनीय उस की तुलना में लापरवाह है।

मैं आमतौर पर अपवाद फेंकने के लिए चिपक जाता हूं, क्योंकि वे स्पष्ट रूप से कुछ गलत हो जाते हैं और सभी webservice टूलकिट्स को संभालने का एक अच्छा तरीका है।

आपके नमूने में मैं "खाता लॉक" संदेश के साथ एक अनधिकृत एक्सेस अपवाद फेंक दूंगा।

स्पष्टीकरण: .NET WCF सेवाएं डिफ़ॉल्ट रूप से FaultContracts पर अपवाद का अनुवाद करती हैं, लेकिन आप इस व्यवहार को बदल सकते हैं।MSDN:Specifying and Handling Faults in Contracts and Services

+0

मैं सहमत नहीं हैं। चूंकि डब्ल्यूसीएफ भाषा-अज्ञेयवादी (कुछ रूप में, कम से कम) माना जाता है, इसलिए आप इस बात की गारंटी नहीं दे सकते कि तार के नीचे एक अपवाद वस्तु को पारित करने से बग समस्याएं उत्पन्न नहीं होंगी। जावा क्लाइंट्स FaultContract ऑब्जेक्ट प्रकार इंटरऑपरेबिलिटी सुनिश्चित कर सकता है क्योंकि यह ओएएसआईएस चश्मे का हिस्सा है। – ZombieSheep

+4

.NET दोष अनुबंधों के अपवाद का अनुवाद करता है। मेरे उत्तर में जोड़े गए लिंक को देखें। –

+0

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

0

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

दुर्भाग्य से, मैं इस समय एक प्रशिक्षण पाठ्यक्रम में हूँ, इसलिए एक पूर्ण जवाब नहीं लिख सकते हैं, लेकिन मैं WCF अनुप्रयोगों में अपवाद प्रबंधन के बारे में सीख रहा हूँ भाग्य के रूप में यह होता है। मैं आज रात अधिक जानकारी के साथ पोस्ट करूंगा। (क्षमा करें यह एक कमजोर जवाब)

6

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

result = CallMethod(); 
if (!result.Success) handleError(); 

result = CallAnotherMethod(); 
if (!result.Success) handleError(); 

result = NotAgain(); 
if (!result.Success) handleError(); 

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

try 
{ 
    CallMethod(); 
    CallAnotherMethod(); 
    NotAgain(); 
} 
catch (Exception e) 
{ 
    handleError(); 
} 

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