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

Question

是否使用通用的DataEventArgs<TData>类，而不是声明和使用自定义EventArgs继承类，在事件声明中，违反。net事件"模式"约定?或者在某些情况下被认为是不好的做法?

命名事件参数的命名约定是使用事件名称并附加后缀"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子类，则仍然会有一些潜在的返工要做。但是，这通常应该是相当小的，并且编译器应该捕获任何问题(无论是使用显式还是匿名处理程序方法)。显然，在最初的开发工作和潜在的更改工作之间需要做出权衡——我使用通用的EventArgs来处理内部事件，因为它非常适合，并且我很少需要在初始发布后更改一个。