C# Benutzerdefinierte EventArgs Frage

Habe ich eine benutzerdefinierte Sammlung, dass ich bin das hinzufügen einer ValidateItem Ereignis. Diese ValidateItem Ereignis wird aufgerufen, wenn ein Element Hinzugefügt oder aktualisiert in der benutzerdefinierten collection.

Möchte ich ermöglichen, abgeleitete Klassen, um in der Lage sein, um das Ereignis zu abonnieren und zu bestimmen, Ihre eigene Logik, ob oder nicht ein Einzelteil ist "gültig" und potenziell verbieten es der Auflistung Hinzugefügt wird, wenn es "invalid".

Aber ich versuche herauszufinden, wie der Anrufer zu der Veranstaltung wissen, was Los ist und wie übergeben Sie die Informationen über das, was da zurück.

Meine benutzerdefinierte eventargs Erben von CancelEventArgs also ich habe die Fähigkeit, übergeben Sie die Abbrechen-bit zurück, um dem Anrufer mit, dass. Aber ich habe nie gesehen, alle Fälle, in denen Fehler-information (error codes, Nachrichten, etc) übergeben bekommt sich wieder in dieser Weise, so Frage ich mich, ob das vielleicht nicht der beste Ansatz sein.

Sollte ich einfach fügen Sie jede Fehlermeldung, die ich wünschte, zu passieren, back zu meiner Benutzerdefinierte eventargs-Klasse, gibt es gute Gründe, die für oder gegen diese? oder gibt es andere, bessere Wege, dies zu erreichen?

Hier ist mein eventargs-Klasse:

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: ich glaube, eine andere Möglichkeit wäre die Verwendung von so etwas wie dieses:

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

Methode in den abgeleiteten Klassen. Obwohl ich dazu Neige zu bevorzugen, die Vermeidung von out-Parametern...

Wenn jemand irgendwelche Ideen auf die vor-und Nachteile jeder Ansatz, den ich lieben würde, zu hören, em!

Dank,
Max

InformationsquelleAutor Max Schilling | 2009-05-13
  1. 3

    Mithilfe von Ereignissen, die für dies ist wahrscheinlich nicht die beste design-Ansatz.

    Da es einer erbenden Klasse, wäre das überschreiben dieses Verhalten, sollte die Methode als geschützt gekennzeichnet werden und virtuelle:

    protected virtual bool Validate(object item);

    Ich auch nicht wie mit out auf Parameter, so dass nach Ihrem ursprünglichen Instinkte zu verwenden EventArgs, sollten Sie wahrscheinlich erstellen Sie eine Klasse zu Kapseln, die Ergebnisse Ihrer überprüfung.

    Beispiel:

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

    Deine Methode wäre dann:

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

   //validate and set results values accordingly

   return result;
}

    Die vor-und Nachteile der Verwendung dieser über Ereignisse, die Ereignisse, die verwendet werden sollen, wenn Sie wollen, zu veröffentlichen, eine Aktion oder Informationen an mehrere Abonnenten. Die Abonnenten sind Klassen, die Sie wissen nichts über. Sie kümmern sich nicht, wer Sie sind oder was Sie tun. Sie sollten nie wirklich weiterleiten von Informationen zurück an die Benachrichtigung Klasse. Sie sollten nur das Ereignis verarbeitet Informationen, die Ihnen gegeben.

    In Ihrem Beispiel, Ihrer geerbten Klasse ist Ihr nur Abonnent. Auf top von, dass Sie wollen in der Lage sein, pass nützliche Informationen zurück zu der übergeordneten Klasse. Vererbung passt dieses erwünschte Verhalten viel besser, und auch ermöglicht es Ihnen, leicht zu implementieren verschiedene Arten der Validierung Klasse. Mit Ereignissen, die Sie hätten halten Sie die Eingabe-code zum anfügen von Ereignishandlern immer und immer wieder (sehr hässlich IMO).

    • Sehr gut gesagt +1
    InformationsquelleAutor jnosek
  2. 1

    Ich glaube nicht, dass das, was Sie beschreiben, wirklich passt den Betrachter, erkennbare Muster, die Sie normalerweise sehen, mit Veranstaltungen.

    Da diese abgeleiteten Klassen würde ich wahrscheinlich schauen, um die Virtualisierung der Validierungs-Methode der Objekte und mit den Kindern einen spezifischen Validierungs-routine.

    • Ich denke, das ist Teil dessen, was mich stört, über diese Ansatz. Aber dann nicht die CancelEventArgs mit einem modifizierbaren Cancel-Eigenschaft bereits gegen das Muster? Also dann, rein hypothetisch, was ist falsch mit dem hinzufügen von ein wenig extra-Daten?
    • Das cancel-Ereignis arg erzählt anderen Veranstaltungen auf der ganzen Linie, dass die Veranstaltung abgesagt wurde. Es ist eine Möglichkeit für andere Beobachter wissen nicht, etwas zu tun. Eines der Probleme mit den events ist, dass alle Abonnenten gehen genannt, bekommen in einigen nicht-deterministischen Reihenfolge, und das ist nicht genau das, was Sie wollen passieren hier, Sie wollen nur eins-Objekte validieren genannt.
    InformationsquelleAutor Dan Blair
  3. 0

    Gut, wenn Sie erstellen Sie Ihre eigenen benutzerdefinierten Validierung Veranstaltungen, zusammen mit benutzerdefinierten Validierung event args, ich würde davon ausgehen, Sie würden es vorziehen, pass zurück status/error codes anstatt werfen Ausnahmen, wenn etwas nicht bestätigen.

    In diesem Fall, wenn Sie wollen, um zu prüfen, ob nicht Ausnahmen werfen, dann ja, ich würde die Felder, die Sie benötigen, um Ihre benutzerdefinierten event-args - Sie sind Gewohnheit bereits, es gibt also keinen Grund, nicht, um Sie zu verlängern, um Ihre Bedürfnisse anzupassen 🙂

    Marc

    InformationsquelleAutor marc_s
  4. 0

    Ein paar schnelle Gedanken:

    Ich würde die Eigenschaften readonly entsprechen dem "normalen" Muster der eventargs-Klassen.

    Vielleicht die Eigenschaften in Bezug auf Fehler Informationen sollten gewickelt werden zusammen in eine ErrorInformation Klasse (das würde es etwas einfacher machen zu gehen, dass Informationen etwa zu anderen Methoden).

    Sich die Frage: was tun, verwenden Sie die EventArgs-Eigenschaft für?

    • Ich denke, readonly wäre in diesem Fall nicht funktionieren. Wenn man sich anschaut, CancelEventArgs, die bool Cancel ist nicht readonly... und das ist für die Weitergabe von Informationen an den Aufrufer zurück, also wirklich alles, was ich Tue, erweitern, dass ein wenig. Nur etwas fällt mir auf, wie "komisch", über diesen Ansatz, ich kann nicht wirklich meine finger auf es. Ich bin mit dem event args übergeben ein Objekt (Element) aus, um die Validierung der Methode die Validierung der Methode tut, was es will... im einfachsten Beispiel wird überprüft, ob das Element nicht bereits vorhanden ist in der Sammlung, und dann wieder Abbrechen, bool und möglicherweise Fehlermeldungen an.
    • Natürlich; ich dachte in die falsche Richtung... eine Andere Sache, erschütterte meinen Geist; was passiert, wenn es zwei verschiedene Listener für Validierung Veranstaltung, wo setzt man Cancel = true und der andere setzt Cancel = false? Ich bekomme das gleiche Gefühl, wie Sie; es ist etwas schlimmes lauern unter der Oberfläche hier ;o)
    InformationsquelleAutor Fredrik Mörk
  5. 0

    Benutzerdefinierte event-args sind speziell verwendet, um Informationen zu und von den event-Handler, also ja, Sie sind ein guter Ort, um Sie gelegt.

    Die andere option wäre eine Ausnahme - dies ist eine ziemlich plumpe, aber sollte aufhören, andere event-Handler wird ausgeführt, für die Veranstaltung.

    InformationsquelleAutor Jason Williams
  6. 0

    EventArgs und CancelEventArgs nicht alle Mitglieder tragen Informationen an die Abonnenten.
    So, normalerweise würden Sie Erben von einer dieser Klassen, und fügen Sie ein oder mehrere Mitglieder zu tragen info.
    Sie können auch Ihre Klasse generisch, so dass Sie nicht haben, um eine neue EventArgs-Klasse, wenn Sie verschiedene Daten zu senden.

    Schließlich, anstatt Ihre eigenen ItemValidationEventHandler delegate-Typ, die Sie verwenden können EventHandler<T>, wobei T der Typ des EventArgs-parameter.

    Auch, Sie brauchen nicht die EventArgs = e Mitglied.

    InformationsquelleAutor mbeckish
Schreibe einen Kommentar