声明事件的首选方式

我对.NET事件模型非常了解。我想我可能会误解该系统的细微差别。

当我开始将事件放入班级时，我将使用标准方式，如下所示：

public event EventHandler<MyEventArgs> MyEvent;

这意味着任何订阅该事件的人都需要类似以下方法：

void HandleThatEvent(object sender, MyEventArgs args){...}

很好，但是我发现我很少关心发送者，因此它使很多方法签名变得肿。

所以我改用声明自己的委托类型

public delegate void MyEventHandler(SomeClass argument);

它减少了混乱，但是在编写处理程序时却给我带来了一个小问题：

eventImplmentor.MyEvent += HandleThatEvent;
.
.
.
void HandleThatEvent(/*oh, um, what arguments does it take? Intellisense isn't telling me*/)

因此，我将不得不返回到委托的声明，然后再查看并回写它们，或者编译它并等待被告知。

因此，现在，我只是用Action，Action<T>或任何模板适合。

public event Action<SomeClass> MyEvent;

这样我就可以将鼠标悬停在事件上，并被告知期望的参数。

毕竟，我的问题是：是否有在C＃中声明事件的最佳实践？我应该回到原来的EventHandler<T>方式还是可以Action<T>接受？

对于简单的内部事件处理，有一些您只是建议使用Action或Action<T>。我倾向于使用标准模式，包括Sender，甚至用于内部事件，因为您永远不知道何时以后才希望公开类或事件，并且我不希望为了重构事件方法而付出代价。它公开。

我确实同意您的观点，事件处理签名比简单情况下的签名要重一些，但是它经过精心设计，可以处理增量迁移，因为随着时间的流逝，可能需要更多的事件参数。总的来说，我会坚持使用标准模式，尤其是因为您如前所述，只有这样做才获得适当的IntelliSense支持。

对于它的价值，我花了一些时间提出了一个不同的事件处理模式：.NET中的事件签名-使用强类型的“发件人”吗？。此处的目标不是删除Sender，而是使它通常是强类型为TSender而不是弱类型为System.Object。效果很好；但是，这样做确实会失去IntelliSense支持，因此这是一个不幸的折衷。

总的来说，我会坚持使用标准模式，但是考虑可能更好的方法很有趣。