为什么 .NET 中的事件使用 sender 作为参数？

Question

当我在 ASPX 页面中为 Web 控件添加事件处理程序时 - 为什么它会传入发件人？ 与在事件处理程序中仅通过其“ID”引用控件相比，使用发送方有什么优势？

我可以看到我是否有一个单独的类来处理事件，并且多个控件将使用事件处理程序。 但是如果我确定只有这个控件会处理这个事件，那么引用控件 ID 而不是将发送者转换为我的对象类型是不是很糟糕？

谢谢！

Answer 1

您似乎只是从 ASP.NET 角度看待 .NET 事件。 .NET 事件模型在整个 .NET Framework 中广泛使用，而不仅仅是用于 ASP.NET 页面和控件。

这种模式很灵活，允许任何（适当的）对象成为事件的来源，允许事件侦听器在引发它以进行进一步处理的对象上“归零”。 请记住，事件不仅需要有一个源和一个侦听器/处理程序。

页面和控件都是对象，因此为了使其足够灵活，发送方类型为 Object。 通过一些编程规则，人们应该能够定义可以引发该事件并将发送方对象转换回原始类型的已知类型。 如果它只是一个字符串控件 ID，则必须找到具有匹配 ID 的控件，这在充满大量控件层次结构的页面中可能并不容易。

Answer 2

优点是可以将相同的事件处理程序附加到多个控件的事件上。 由于您不知道在这种情况下引发事件的控件，因此您可以使用sender参数来引用它。

Answer 3

控件不需要有 ID，事件可以被多个控件抛出。 使对象成为发送者意味着您可以从没有 ID 的控件和一般对象中捕获事件。

Answer 4

作为上述答案的补充，当您在Repeater 中创建按钮时，发件人可能会很方便。 假设您遍历了 100 个订单或与此相关的任何其他数据，并且您想要检查一个显示“确定”的按钮，您不希望能够按两次“确定”。

因此，在您的方法中，您可以将发件人用作：

Button b = sender as Button;
b.Enabled = false;

Answer 5

不使用控件 ID 来引用引发事件的实例的另一个原因是事件系统跨越 .NET 框架，而不仅仅是 ASP.NET。 引发事件的其他类型不一定具有控件 ID（甚至可能根本不是控件）。

Answer 6

菲利普, dtb

以你的例子，我们正在进入事件处理的危险世界。 将发送者对象类型转换为其他类型实际上将知识“注入”到事件处理程序中，即该事件处理程序正在被按钮调用。 这使得事件处理程序无法被其他类型的控件或类使用。

共享事件处理程序听起来是个好主意，但根据我自己的经验（并查看其他人的代码），它被滥用的次数比使用的次数要多。 的确，对于中继器，您没有太多选择。 我想说的只是小心你编码到实际事件处理程序中的内容，如果它超过三行，请考虑创建一个函数。

挑剔：

Button b = sender as Button; 
if(b != null)
{
  b.Enabled = false; 
}

或者甚至更好：

Button clickedButton = sender as Button; 
if(clickedButton != null)
{
  clickedButton.Enabled = false; 
}

问题：为什么 Enabled 属性被呈现为 Type ？