سؤال

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

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

ولكن أنا في محاولة لمعرفة كيفية السماح المتصل إلى الحدث يعرفون ما يجري وكيفية تمرير المعلومات حول ما يجري على ظهره.

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

وأود أن مجرد إضافة أي بيانات الخطأ التي أود أن تمرير العودة الى بلدي مخصص الطبقة eventargs، هل هناك أسباب وجيهة لصالح أو ضد هذا؟ أم أن هناك أخرى، أفضل السبل لتحقيق ذلك؟

وهنا صفي eventargs:

public delegate void ItemValidationEventHandler(object sender, ItemValidationEventArgs e);

public class ItemValidationEventArgs : CancelEventArgs
{
    public ItemValidationEventArgs(object item, ObjectAction state, EventArgs e)
    {
        Item = item;
        State = state;
        EventArgs = e;
    }

    public ItemValidationEventArgs(object item, ObjectAction state) : this(item, state, new EventArgs())
    {
    }

    public ItemValidationEventArgs() : this(null, ObjectAction.None, new EventArgs())
    {
    }

    // is there a better way to pass this info?
    public string ErrorMessage {get; set;}
    public int ErrorNumber {get;set;}

    public object Item { get; private set; }
    public ObjectAction State { get; private set; }

    public EventArgs EventArgs { get; private set; }
}

وUPDATE: أعتقد أن الخيار الآخر آخر يتمثل في استخدام شيء من هذا القبيل:

virtual bool Validate(object item, ObjectAction action, out string errorMessage) 

والأسلوب في الفئات المشتقة منها. على الرغم من أنني تميل إلى تفضيل تجنب الخروج المعلمات ...

وإذا كان أي شخص لديه أي أفكار حول إيجابيات وسلبيات كل نهج أحب أن أسمع م!

وشكرا، ماكس

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

المحلول

وعن طريق فعاليات لهذا ربما لا يكون نهج أفضل تصميم.

ونظرا لأنه هو فئة وراثة أنه سيتم تجاوز هذه المشكلة، يجب وضع علامة الأسلوب كما المحمية والظاهري:

protected virtual bool Validate(object item);

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

مثال:

class ValidationResult
{
     public string ResultMessage{get;set;}
     public bool IsValid {get;set;}
}

وأسلوب لديك بعد ذلك على النحو التالي:

protected virtual ValidationResult Validate(object item)
{
   ValidationResult result = new ValidationResult();

   // validate and set results values accordingly

   return result;
}

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

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

نصائح أخرى

وأنا لا أعتقد أن ما كنت تصف حقا يناسب المراقب، النمط للمراقبة والتي سوف تشاهد عادة مع الأحداث.

ومنذ وتستمد هذه الفئات أنا ربما ننظر إلى virtualizing طريقة التحقق من صحة الكائنات وجود أطفال توفر روتين التحقق من صحة محدد.

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

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

ومارك

وزوجان من الأفكار سريعة:

وأود أن جعل خصائص للقراءة فقط لتتوافق مع نمط "العادي" من الطبقات eventargs.

وربما الخصائص المتعلقة خطأ المعلومات ينبغي أن تكون ملفوفة معا في بعض الطبقة ErrorInformation (التي من شأنها أن تجعل من الأسهل قليلا لتمرير تلك المعلومات في جميع أنحاء لأساليب أخرى).

سؤال: ماذا كنت تستخدم خاصية EventArgs ل

تستخدم

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

والخيار الآخر سيكون بطرح استثناء - وهذا هو ثقيل الوطأة إلى حد ما، ولكن يجب أن تتوقف معالجات الأحداث الأخرى من إعدامهم لهذا الحدث

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

وأخيرا، بدلا من جعل نوع خاص ItemValidationEventHandler مندوب الخاص بك، يمكنك استخدام EventHandler<T>، حيث T هو نوع من المعلمة EventArgs الخاص بك.

وبالإضافة إلى ذلك، لا تحتاج إلى EventArgs ه = الأعضاء.

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