【问题标题】:Ok to use DataEventArgs<TData> instead of customized event data class?可以使用 DataEventArgs<TData> 而不是自定义事件数据类吗?
【发布时间】:2013-04-02 14:05:36
【问题描述】:

在事件声明中使用通用 DataEventArgs&lt;TData&gt; 类,而不是声明和使用自定义 EventArgs 继承类,是否违反了 .Net 事件“模式”约定?或者在某些情况下被认为是不好的做法?

(命名事件参数的命名约定是使用事件名称并附加后缀“EventArgs”。使用DataEventArgs&lt;TData&gt;会省略事件名称,尽管它会向您显示事件的类型传输的数据。)

您可能会争辩说,通用 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;
    }
}

【问题讨论】:

标签: .net events generics event-handling


【解决方案1】:

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

对于不属于公共 API 的事件,如果 EventArgs 子类因特定事件而更改,则仍有一些潜在的返工工作要做,因为通用子类不再适合。但是,这通常应该是相当少的,并且编译器应该捕获任何问题(无论是使用显式还是匿名处理程序方法)。显然,在最初的开发工作和潜在的更改工作之间需要进行权衡——首先,我使用通用的 EventArgs 来处理非常适合的内部事件,而且我很少需要在初始之后进行更改释放。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2013-03-20
    • 2021-04-10
    • 2018-08-13
    • 2011-01-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-15
    相关资源
    最近更新 更多