WCF - الأخطاء / الاستثناءات مقابل الرسائل

Question

نحن نجري حاليًا نقاشًا حول ما إذا كان من الأفضل إلقاء الأخطاء عبر قناة WCF، بدلاً من تمرير رسالة تشير إلى الحالة أو الاستجابة من الخدمة.

تأتي الأخطاء مع دعم مدمج من WCF حيث يمكنك استخدام معالجات الأخطاء المضمنة والرد وفقًا لذلك.ومع ذلك، فإن هذا يحمل عبئًا حيث أن طرح الاستثناءات في .NET قد يكون مكلفًا للغاية.

يمكن أن تحتوي الرسائل على المعلومات الضرورية لتحديد ما حدث لمكالمة الخدمة الخاصة بك دون تحميل أي استثناء.ومع ذلك، فهو يحتاج إلى عدة أسطر من التعليمات البرمجية المتكررة لتحليل الرسالة وتحديد الإجراءات التي تتبع محتوياتها.

لقد حاولنا إنشاء كائن رسالة عام يمكننا استخدامه في خدماتنا، وهذا ما توصلنا إليه:

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

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

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

إذا أعادت جميع مكالمات الخدمة الخاصة بي هذا العنصر، فيمكنني التحقق باستمرار من خاصية "النجاح" لتحديد ما إذا كان كل شيء يسير على ما يرام.لدي بعد ذلك سلسلة رسائل خطأ في الحدث تشير إلى حدوث خطأ ما، وعنصر عام يحتوي على Dto إذا لزم الأمر.

يجب تسجيل معلومات الاستثناء في خدمة التسجيل المركزية وعدم تمريرها مرة أخرى من الخدمة.

أفكار؟تعليقات؟أفكار؟اقتراحات؟

بعض التوضيحات الإضافية حول سؤالي

إحدى المشكلات التي أواجهها فيما يتعلق بالعقود الخاطئة هي توصيل قواعد العمل.

مثلاً، إذا قام شخص ما بتسجيل الدخول وتم قفل حسابه، كيف يمكنني إبلاغ ذلك؟من الواضح أن تسجيل الدخول الخاص بهم فشل، لكنه فشل بسبب "الحساب مغلق".

اذا يمكنني:

أ) استخدم قيمة منطقية، وقم بإلقاء خطأ مع قفل حساب الرسالة

ب) قم بإرجاع AuthenticatedDTO بالمعلومات ذات الصلة

Answer 1

ومع ذلك، فإن هذا يحمل عبئًا حيث أن طرح الاستثناءات في .NET قد يكون مكلفًا للغاية.

أنت تقوم بإجراء تسلسل وإلغاء تسلسل الكائنات إلى XML وإرسالها عبر شبكة بطيئة.الحمل الناتج عن طرح الاستثناء لا يكاد يذكر مقارنة بذلك.

عادةً ما ألتزم بطرح الاستثناءات، لأنها تشير بوضوح إلى حدوث خطأ ما الجميع تتمتع مجموعات أدوات خدمة الويب بطريقة جيدة للتعامل معها.

في العينة الخاصة بك، سأقوم بطرح UnauthorizedAccessException مع الرسالة "Account Locked".

إيضاح: تقوم خدمات .NET wcf بترجمة الاستثناءات إلى FaultContracts بشكل افتراضي، ولكن يمكنك تغيير هذا السلوك. MSDN: تحديد ومعالجة الأخطاء في العقود والخدمات

Answer 2

إذا فكرت في الاتصال بالخدمة مثل الاتصال بأي طريقة أخرى، فقد يساعد ذلك في وضع الأمور في نصابها الصحيح.تخيل لو أن كل طريقة اتصلت بها أعادت حالة، وكان الأمر متروكًا لك للتحقق مما إذا كانت صحيحة أم خاطئة.سيكون الأمر مملاً للغاية.

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();
}

وفي الوقت نفسه، من خلال إرجاع النتيجة فإنك تضع المزيد من المسؤولية على عاتق العميل.ربما تعرف جيدًا ضرورة التحقق من وجود أخطاء في الكائن الناتج، ولكن يأتي John Doe ويبدأ في الاتصال بخدمتك، غافلًا عن وجود أي خطأ لأنه لم يتم طرح استثناء.هذه قوة عظيمة أخرى للاستثناءات وهي أنها تعطينا صفعة جيدة على الوجه عندما يكون هناك خطأ ما ويحتاج إلى العناية به.

Answer 3

سأفكر جديًا في استخدام كائنات FaultContract وFaultException للتغلب على هذا الأمر.سيسمح لك هذا بتمرير رسائل خطأ ذات معنى مرة أخرى إلى العميل، ولكن فقط عند حدوث حالة خطأ.

لسوء الحظ، أنا في دورة تدريبية في الوقت الحالي، لذا لا يمكنني كتابة إجابة كاملة، ولكن لحسن الحظ، فأنا أتعلم إدارة الاستثناءات في تطبيقات WCF.سأعود بنشر المزيد من المعلومات الليلة.(آسف إنها إجابة ضعيفة)