为什么*应该*我们使用EventHandler [英] Why *should* we use EventHandler

问题描述

我讨厌EventHandler.我讨厌如果要对它进行任何操作，都必须转换sender.我讨厌必须创建一个继承自EventArgs的新类才能使用EventHandler<T>.

I hate EventHandler. I hate that I have to cast the sender if I want to do anything with it. I hate that I have to make a new class inheriting from EventArgs to use EventHandler<T>.

我总是被告知EventHandler是传统，等等……等等.但是我找不到这个教条仍然存在的原因.

I've always been told that EventHandler is the tradition and blah, blah...whatever. But I can't find a reason why this dogma is still around.

有没有理由创建一个新的委托人是一个坏主意?

Is there a reason why it would be a bad idea to make a new delegate:

delegate void EventHandler<TSender, T>(TSender sender, T args);

这样sender将是类型安全的，并且我可以将我想要的任何内容作为参数传递(如果需要，可以包括自定义EventArgs).

That way the sender will be typesafe and I can pass whatever the heck I want as the arguments (including custom EventArgs if I so desire).

推荐答案

如果您完全信任的代码将部分第三方信任的代码托管在第三方代码中，则实际上有充分的理由要求第二个参数从EventArgs派生.

There actually is a good reason for requiring the second argument to derive from EventArgs if your fully-trusted code hosts third-party code as partially-trusted.

由于事件处理委托的回调是在引发代码而不是第三方代码的上下文中完成的，因此恶意第三方代码有可能将特权系统操作添加为事件处理程序，从而有可能执行通过在完全受信任的上下文中运行代码(部分受信任的上下文无法运行)来升级特权攻击.

Because the callback to the event handling delegate is done in the context of the raising code and not the third party code, it is possible for malicious third-party code to add a privileged system operation as an event handler and thus potentially execute an escalation of privilege attack by running code in your fully-trusted context that their partially-trusted context could not run.

例如，如果您将处理程序声明为类型int -> void，则第三方代码可能会排队进入YourEvent += Enviroment.Exit(-1)，并使您无意中退出该过程.这显然会引起一个易于检测的问题，但是可能有更多的恶意API可能会被排入队列以执行其他操作.

For example, if you declare a handler as type int -> void then the third-party code could enqueue YourEvent += Enviroment.Exit(-1) and have you exit the process unintentionally. This would obviously cause an easy-to-detect problem, but there are far more malicious APIs that could be enqueued to do other things.

当签名为(object, EventArgs) -> void时，则框架中没有可排队的特权操作，因为它们均不与此签名兼容.这是框架中安全代码检查的一部分，以确保做到这一点(不幸的是，我在阅读本文时无法找到源文件.)

When the signature is (object, EventArgs) -> void then there are no privileged operations in the framework that can be enqueued because none of them are compatible with this signature. It's part of the security code review in the framework to ensure this (unfortunately I cannot find the source where I read this).

因此，在某些情况下，对于为什么应使用标准模式存在有效的安全问题.如果您100％确信在这种情况下将永远不会使用您的代码，那么事件签名指南就不那么重要了(除了其他开发人员认为WTF的情况除外)，但是如果确实如此，则应该遵循它.

So in certain circumstances there are valid security concerns as to why you should use the standard pattern. If you're 100% sure your code will never be used in these circumstances then the event signature guideline isn't as important (apart from other developers thinking WTF), but if it might be then you should follow it.

这篇关于为什么*应该*我们使用EventHandler的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！