我应该使用EventArgs还是简单的数据类型？

Question

我目前正在创建一个有趣和实践的库，我想知道，在举办活动时，如何选择传递自己的EventArgs派生词或仅传递数据类型。

例如，在我的图书馆中，我有类似的东西：

public delegate void LostConnectionEventHandler(string address);
public delegate void MessageReceieved(byte[] bytes);

这是什么标准做法？我应该将string address替换为ConnectionEventArgs，将byte[] bytes替换为MessageEventArgs吗？

我知道其中任何一个都可以正常工作，这个问题可能是主观的但我仍然对高级程序员在决定是否包含他们自己的EventArgs或直接传递数据时所经历的思维过程感到好奇。

谢谢！

Answer 1

  

.NET Framework指南指出用于的委托类型   一个事件应该带两个参数，一个“对象源”参数   指示事件的来源，以及“e”参数   封装有关该事件的任何其他信息。的类型   “e”参数应该来自EventArgs类。对于活动   .NET Framework没有使用任何其他信息   已经定义了一个合适的委托类型：EventHandler。

参考：http://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx

另一个有用的信息：http://msdn.microsoft.com/en-us/library/ms229011.aspx

Answer 2

我个人喜欢从EventArgs，

派生的想法

如果您必须传递状态信息并聚合对象，则可以轻松完成，请参阅

例如

MouseEventArgs类型。

使用OOP方法，如果你有一个接受类型为EventArgs的对象的事件/构造，你可以依赖这样一个事实：从它派生的每个对象都将以相同的方式工作，而如果你有另一种类型的对于不共享相同基类的对象，最终可能会破坏某些内容。

很难证明和重现，但可能取决于设计，因为事件是专门用于EventArgs及其后代的代表

Answer 3

在一个较大的项目中，拥有一个EventArgs类有助于最小化您必须修改的代码，在某些情况下，当您的事件需要其他数据时。我通常会优先使用EventArgs方式而不是直接值。

Answer 4

不需要从EventArgs派生，但约定遵循共同（Introduce Parameter Object）重构规则。这条规则的基本原理已有详细记载。

Answer 5

在我的项目中，当参数数量大于1时，我使用EventArgs！查看NotifyPropertyChanged事件，它有一个参数，它不是EventArgs类型。