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

正在使用通用的DataEventArgs<TData>类，而不是在事件声明中声明和使用自定义的 EventArgs 继承类，这违反了 .Net 事件“模式”约定吗？或者在某些情况下被认为是不好的做法？

(The naming命名事件参数的约定是使用事件名称并附加后缀“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）的建议或约定指示，反之亦然。

所以，只要有one我想包含在事件数据中的数据，是否有任何原因我应该使用自定义事件数据类（例如 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;
    }
}

没有理由不对非公共事件使用通用的 EventArgs 子类。然而，对于属于真正公共 API 一部分的事件，由于潜在的向后兼容性问题，事情会变得有点棘手。对于公开使用的事件，创建特定于事件的 EventArgs 子类将使您能够灵活地添加成员，而不会影响 API 使用者。

对于不属于公共 API 的事件，如果针对特定事件更改了 EventArgs 子类，则仍然需要进行一些潜在的返工，因为通用子类不再适合。但是，这通常应该是相当小的，并且编译器应该捕获任何问题（无论使用显式还是匿名处理程序方法）。显然，在初始开发工作和潜在的更改工作之间需要进行权衡 - fwiw，我对内部事件使用通用的 EventArgs，它非常适合，并且我很少需要在初始开发后更改它发布。