¿Tiene .NET un EventArgs<T> integrado?

StackOverflow https://stackoverflow.com/questions/3312134

  •  27-09-2020
  •  | 
  •  

Pregunta

Me estoy preparando para crear una clase EventArgs genérica para argumentos de eventos que llevan un solo argumento:

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

Antes de hacer eso, ¿C# tiene la misma característica integrada en el lenguaje?Creo recordar haberme encontrado con algo así cuando salió C# 2.0, pero ahora no puedo encontrarlo.

O para decirlo de otra manera, ¿tengo que crear mi propia clase EventArgs genérica o C# proporciona una?Gracias por tu ayuda.

¿Fue útil?

Solución

No.Probablemente estabas pensando en EventHandler<T>, que le permite definir el delegado para cualquier tipo específico de EventArgs.

Yo personalmente no siento eso EventArgs<T> Sin embargo, encaja igual de bien.La información utilizada como "carga útil" en los argumentos del evento debería ser, en mi opinión, una clase personalizada para dejar muy claro su uso y las propiedades esperadas.El uso de una clase genérica evitará que puedas colocar nombres significativos.(¿Qué representa "Datos"?)

Otros consejos

Debo decir que no entiendo todos los 'puristas' aquí. I.E. Si ya tiene una clase de bolsa definida, lo que tiene todos los detalles, propiedades, etc., ¿por qué el hack crea una clase extra innecesaria para poder seguir el mecanismo de evento / args, estilo de la firma? cosa es, no todo lo que está en .NET, o está "desaparecido de" para eso, es "bueno", la MS ha estado corrigiendo "durante años ... Yo diría que solo vaya y creo uno, como lo hice, porque lo necesitaba así, y me ahorré mucho tiempo,

existe.Al menos, lo hace ahora.

Puede encontrar DataEventArgs<TData> en algunos conjuntos de Microsoft diferentes/ Pacientes de nombres, por ejemplo, Microsoft.PRACTICES.PRISM.EVENTOS .Sin embargo, estos son espacios de nombres que es posible que no encuentres natural incluir en su proyecto, por lo que podría usar su propia implementación.

En caso de que elija no usar prisma , pero aun así quiere probar unEnfoque genérico eventargs . 

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

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

// Utilice el siguiente código de muestra para declarar el evento OBJADDED 

public event EventHandler<GenericEventArgs<TargetObjType>> ObjAdded;

// Utilice el siguiente código de muestra para levantar Evento OBJADDED 

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

// y Finnaly Puede suscribir su evento OBJADDED 

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

No hay argamentos genéricos incorporados. Si sigue a Microsoft EventHandler Pattern, luego implementa sus eventos derivados como usted sugirió: public class MyStringChangedEventArgs : EventArgs { public string OldValue { get; set; } }.

Sin embargo, si su guía de estilo de equipo acepta una simplificación: su proyecto puede usar eventos livianos, como este: 

public event Action<object, string> MyStringChanged;

Uso: 

// 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);

Por lo general, los proyectos POC utilizan el último enfoque.En aplicaciones profesionales, sin embargo, tenga en cuenta la justificación de FX COP # CA1009: HTTPS: //msdn.microsoft.com/en-us/library/ms182133.aspx

El problema con un tipo genérico es que incluso si DeriveType habla de BasoType, EventArgs (DerivedType) no habría heredado de EventArgs (Basetype).El uso de EventArgs (BaseType) evitaría, por lo tanto, más tarde usando una versión derivada del tipo.

La razón por la que esto no existe es porque lo que terminaría sucediendo es que lo implementa, y luego, cuando vaya a completar la T, debe crear una clase con propiedades inequívocas que actúen como la bolsa de datos para su eventoARG, pero a la mitad de la implementación de que te das cuenta de que no hay ninguna razón por la que no hagas esa clase heredada de EventArgs y llámalo bien.

A menos que solo desee una cadena o algo así básico para su bolsa de datos, en cuyo caso, es probable que los estándares de EventArgs sean estándar en .NET, que están destinados a servir a cualquier propósito simple que está recibiendo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top