可以使用DataEventArgs <TData>而不是自定义事件数据类吗？

Question

使用泛型DataEventArgs<TData>类,而不是在事件声明中声明和使用自定义EventArgs继承类,违反.Net事件"模式"约定？或者在某些情况下考虑不好的做法？

(命名事件args 的命名约定是使用事件名称并附加后缀"EventArgs".使用DataEventArgs<TData>省略事件名称,尽管它显示了传输的数据类型.)

您可能会争辩说,通用DataEventArgs类对扩展是封闭的,例如添加另一个属性,除非您可以修改用于TData的类.

---

更长的解释:

在声明包含一些数据的标准委托事件时,我理解标准事件"模式"约定是使用通用的EventHandler委托声明它:

public event EventHandler<SomethingHappendEventArgs> SomethingHappend;

具体SomethingHappendEventArgs是什么声明的东西

public class SomethingHappendEventArgs : EventArgs
{
    public SomeDataType Value { get; private set; }
    public SomethingHappendEventArgs(SomeDataType data)
    {
        this.Value = data;
    }
}

当谷歌搜索时,我注意到有几个Microsoft命名空间提供了一个通用的DataEventArgs类,(包括Microsoft.Practices.Prism.Events).但是,我无法找到任何推荐或约定指示何时使用它而不是自定义事件数据类,如SomethingHappendEventArgs,反之亦然.

所以,只要有一个数据块,我要在事件数据包括,是否有我应使用自定义的事件数据类,像SomethingHappendEventArgs,而不是宣布这样的事件的任何原因？

public event EventHandler<DataEventArgs<SomeDataType>> SomethingHappend;

泛型DataEventArgs可以声明如下:

public class DataEventArgs<TData> : EventArgs
{
    public TData Value { get; private set; }
    public DataEventArgs(TData value)
    {
        this.Value = value;
    }
}

Answer 1

没有理由不为非公共事件使用通用的EventArgs子类.但是,对于属于真正公共API的事件,由于潜在的向后兼容性问题,事情会变得有点棘手.对于公开使用的事件,创建特定于事件的EventArgs子类将使您可以灵活地添加成员而不会影响API使用者.

对于不属于公共API的事件,如果针对特定事件更改了EventArgs子类,仍然会有一些潜在的返工要做,因为通用子类不再适合.但是,这通常应该是相当小的,并且编译器应该捕获任何问题(是否使用显式或匿名处理程序方法).显然,在初始开发工作和潜在的更改工作之间需要进行权衡 - fwiw,我使用通用EventArgs进行内部事件,这是一个很好的选择,我很少需要在初始化后更改一个发布.