考虑这种情况.我有一个对象,让我们称它为...... Foo.Foo引发了一个名为"Loaded"的简单事件.作为活动信息的一部分,消费者需要知道哪个foo对象引发了该事件.我们的团队采用了以下模式.
1)创建一个继承自EventArgs的新类 - 例如,FooEventArgs:System.EventArgs.
2)将类型为Foo的属性添加到FooEventArgs中,该属性通过构造函数传入来设置.
3)使用EventHandler的通用版本声明事件,所以
public event EventHandler<FooEventArgs> Loaded;
4)使用以下签名从Foo类提升事件:
Loaded(this, new FooEventArgs(this));
本质上它的作用是使"发送者"成为foo对象,但它也将foo对象引用作为强类型属性放入事件参数中.
这样做的一个优点是,当他们处理事件时,没有人必须打扰"发送者",这降低了事件消费者和事件提升者之间的耦合.另一个"优势"是,如果事件提升者的类型必须改变,因此强类型属性(希望永远不会发生),那么当它作为null出现时,不是简单地让代码在转换时开始失败, API实际上已经破解,因此可以在编译时修复.
对我来说,这种模式似乎有点矫枉过正.他们应该更多地信任"sender"参数,并放弃自定义事件参数吗？我的团队认为没有人真正使用sender参数.传递对事件提升对象的引用的最佳实践是什么？
编辑:到目前为止很好的反馈,我会在接受之前将其打开一天左右.
常见的模式是使用发件人而不是将发件人分别添加到EventArgs.自定义EventArgs用于其他状态,如树事件的树节点,可取消事件的(可设置)布尔值等.
我们使用共同模式,因为它也被BCL类使用,并且对"自制事件"产生影响可能会造成混淆.此外,我们有一个全局IoC发布者 - 订阅者模式,但这个模式仅适用于普通的EventHandler委托签名,因为事先不知道类型.在这种情况下,无论如何都需要强制转换(例如自定义EventArgs),因此我们也可以投射发送者.