我应该使用EventArgs还是简单的数据类型？
我正在创建一个有趣和实践的库，我想知道，在举办活动时，如何选择传递自己的EventArgs衍生物或仅仅是数据类型。
例如，在我的库中我有这样的东西：
public delegate void LostConnectionEventHandler(string address); public delegate void MessageReceieved(byte[] bytes); 这是什么标准做法？ 我应该用MessageEventArgs替换string address和用MessageEventArgs替换byte[] bytes吗？
我知道其中一个工作得很好而且这个问题可能是主观的但我仍然对高级程序员在决定是否包含他们自己的EventArgs或直接传递数据时所经历的思考过程感到好奇。
谢谢！
.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
我个人喜欢从EventArgs派生的想法，
如果您必须传递状态信息并聚合对象，则可以轻松完成，请参阅
例如， MouseEventArgs类型。
使用OOP方法，如果你有一个接受EventArgs类型对象的事件/构造，你可以依赖这样一个事实：从它派生的每个对象将以相同的方式工作，而如果你有另一种不共享的对象基类，你最终可能会破坏一些东西。
很难certificate和重现，但可能取决于设计，因为事件是专门用于与EventArgs及其后代一起工作的代表
在一个较大的项目中，拥有EventArgs类有助于最小化您必须修改的代码，当您的事件在某些情况下需要其他数据时。 我通常优先使用EventArgs方式而不是直接值。
在我的项目中，当参数数量大于1时，我使用EventArgs！ 查看NotifyPropertyChanged事件，它有一个参数，它不是EventArgs类型。
不需要从EventArgs派生，但是约定遵循通用（ 引入参数对象 ）重构规则。 这条规则的基本原理已有详细记载。