سؤال

أنا أكتب خدمة WCF لأول مرة.الخدمة وجميع عملائها (على الأقل في الوقت الحالي) مكتوبة بلغة C#.يجب أن تقوم الخدمة بالكثير من عمليات التحقق من صحة المدخلات على البيانات التي يتم تمريرها، لذلك أحتاج إلى طريقة ما للإشارة إلى البيانات غير الصالحة مرة أخرى إلى العميل.لقد قرأت الكثير عن الأخطاء والاستثناءات، والتفاف الاستثناءات في الأخطاء، والكثير من المقالات المتضاربة التي تزيد من إرباكي.ما هي الطريقة الصحيحة للتعامل مع هذه الحالة؟

هل يجب أن أتجنب الاستثناءات تمامًا وأرسل رسالة إرجاع النتائج؟هل يجب علي إنشاء خطأ خاص، أو استثناء خاص، أو مجرد طرح استثناءات ArgumentExceptions كما أفعل مع وظيفة التحقق من صحة غير WCF؟

الكود الموجود لدي الآن (متأثر بـ MSDN) يكون:

[DataContract]
public class ValidationFault
{
    [DataMember]
    public Dictionary<string, string> Errors { get; private set; }

    [DataMember]
    public bool Fatal { get; private set; }

    [DataMember]
    public Guid SeriesIdentifier { get; private set; }

    public ValidationFault(Guid id, string argument, string error, bool fatal)
    {
        SeriesIdentifier = id;
        Errors = new Dictionary<string, string> {{argument, error}};
        Fatal = fatal;
    }

    public void AddError(string argument, string error, bool fatal)
    {
        Errors.Add(argument, error);
        Fatal |= fatal;
    }
}

وفي الطريقة يوجد [FaultContract(typeof(ValidationFault))].فهل هذه هي الطريقة "الصحيحة" للتعامل مع هذا الأمر؟

هل كانت مفيدة؟

المحلول

إذا كنت تقوم بالتحقق من صحة العميل ويجب أن يكون لديك قيم صالحة بمجرد تمريرها إلى الطريقة (استدعاء خدمة الويب)، فسأطرح استثناءً.يمكن أن يكون استثناءً يشير إلى أن المعلمة غير صالحة باسم المعلمة.(يرى:استثناء الوسيطة)

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

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

افتراضي لأي خدمة WCF هو أنه سيكون هناك أكثر من واجهة مستخدم واحدة.يمكن أن يكون أحدهما واجهة مستخدم ويب الآن، ولكن لاحقًا قد أضيف أخرى باستخدام WinForms أو WinCE أو حتى تطبيق هاتف iPhone/Android أصلي لا يتوافق مع ما تتوقعه من عملاء .NET.

نصائح أخرى

طرح الاستثناء ليس مفيدًا من خدمة WCF، لماذا لا؟لأنه يعود كخطأ واضح وتحتاج إلى ذلك

أ) قم بتعيين الخطأ ليشمل الاستثناءات

ب) تحليل الخطأ للحصول على نص الاستثناء ومعرفة ما حدث.

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

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

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

باستخدام entlib مع WCf، يمكنك الحصول على قدر كبير من التحقق من الصحة والإبلاغ عن الأخطاء دون الحاجة إلى كتابة الكثير من التعليمات البرمجية

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top