.NET dispone di un EventArgs <T> integrato?

Mi sto preparando a creare una classe EventArgs generica per argomenti evento che contengono un singolo argomento:

public class EventArg<T> : EventArgs
{
    // Property variable
    private readonly T p_EventData;

    // Constructor
    public EventArg(T data)
    {
        p_EventData = data;
    }

    // Property for EventArgs argument
    public T Data
    {
        get { return p_EventData; }
    }
}

Prima di farlo, C # ha la stessa funzionalità incorporata nel linguaggio? Mi sembra di ricordare di essermi imbattuto in qualcosa del genere quando è uscito C # 2.0, ma ora non riesco a trovarlo.

O, in altre parole, devo creare la mia classe EventArgs generica o C # ne fornisce una? Grazie per l'aiuto.

No. Probabilmente stavi pensando EventHandler<T>, che ti consente di definire il delegato per qualsiasi tipo specifico di EventArgs.

Personalmente, però, non credo che EventArgs<T>sia così buono. Le informazioni utilizzate come "payload" nell'evento args dovrebbero essere, a mio parere, una classe personalizzata per rendere molto chiari il suo utilizzo e le proprietà attese. L'uso di una classe generica ti impedirà di inserire nomi significativi. (Cosa rappresenta "Dati"?)

Devo dire che non capisco tutti i "puristi" qui. cioè, se hai già una classe bag definita - che ha tutte le specifiche, le proprietà ecc. - perché l'hack crea una classe extra non necessaria solo per poter seguire il meccanismo degli eventi / argomenti, lo stile della firma? il fatto è che - non tutto ciò che è in .NET - o che è "mancante da" per quella materia - è "buono" - la SM si sta "correggendo" da sola per anni ... Direi di andare e crearne uno - come ho fatto io - perché ne avevo bisogno proprio così - e mi ha fatto risparmiare un sacco di tempo,

Esiste. Almeno adesso lo fa.

È possibile trovare DataEventArgs<TData>in alcuni diversi assembly / spazi dei nomi Microsoft , ad esempio Microsoft.Practices.Prism.Events . Tuttavia questi sono spazi dei nomi che potresti non trovare naturale includere nel tuo progetto, quindi potresti semplicemente usare la tua implementazione.

Nel caso in cui scegli di non utilizzare Prism , ma desideri comunque provare un approccio EventArgs generico .

public class GenericEventArgs<T> : EventArgs
{
    public T EventData { get; private set; }

    public GenericEventArgs(T EventData)
    {
        this.EventData = EventData;
    }
}

// Utilizzare il seguente codice di esempio per dichiarare l' evento ObjAdded

public event EventHandler<GenericEventArgs<TargetObjType>> ObjAdded;

// Utilizzare il seguente codice di esempio per generare l' evento ObjAdded

private void OnObjAdded(TargetObjType TargetObj)
{
    if (ObjAdded!= null)
    {
        ObjAdded.Invoke(this, new GenericEventArgs<TargetObjType>(TargetObj));
    }
}

// E finalmente puoi iscriverti al tuo evento ObjAdded

SubscriberObj.ObjAdded +=  (object sender, GenericEventArgs<TargetObjType> e) =>
{
    // Here you can explore your e.EventData properties
};

NON CI SONO ARG GENERICI INTEGRATI. Se si seguono modello Microsoft EventHandler, quindi di implementare i tuoi EventArgs derivati come da te suggerito: public class MyStringChangedEventArgs : EventArgs { public string OldValue { get; set; } }.

TUTTAVIA, se la guida di stile del tuo team accetta una semplificazione, il tuo progetto può utilizzare eventi leggeri, come questo:

public event Action<object, string> MyStringChanged;

utilizzo:

// How to rise
private void OnMyStringChanged(string e)
{
    Action<object, string> handler = MyStringChanged;    // thread safeness
    if (handler != null)
    {
        handler(this, e);
    }
}

// How to handle
myObject.MyStringChanged += (sender, e) => Console.WriteLine(e);

Di solito i progetti PoC utilizzano quest'ultimo approccio. Nelle applicazioni professionali, tuttavia, tieni presente la giustificazione del poliziotto FX # CA1009: https://msdn.microsoft.com/en-us/library/ms182133.aspx

Il problema con un tipo generico è che anche se DerivedType eredita da BaseType, EventArgs (DerivedType) non erediterà da EventArgs (BaseType). L'utilizzo di EventArgs (BaseType) impedirebbe quindi l'utilizzo successivo di una versione derivata del tipo.

Il motivo per cui questo non esiste è perché ciò che finirebbe per accadere è che tu lo implementi, e poi quando vai a riempire la T dovresti creare una classe con proprietà univoche fortemente tipizzate che funge da contenitore di dati per il tuo evento arg, ma a metà dell'implementazione ti rendi conto che non c'è motivo per cui non fai semplicemente in modo che quella classe erediti da EventArgs e la chiami buona.

A meno che tu non voglia solo una stringa o qualcosa di simile di base per la tua borsa di dati, nel qual caso ci sono probabilmente classi EventArgs standard in .NET che hanno lo scopo di servire qualunque semplice scopo tu stia ottenendo.