Question

在执行大量ASP.NET页面（.NET 2.0）时，我的代码隐藏通常包含页面对象上的事件处理程序。 GridView_RowCommand，Button_Click等所有常见的嫌疑人。所有EventHandler派生的东西都有一个共同点，那就是他们的第一个参数是一个对象，通常标记为“sender”。

在ASP.NET代码隐藏中，我真的没有看到它的重点。如果我有GridCustomers_RowCommand并且我需要对GridCustomers做一些事情，我可以从代码隐藏中访问它，而不是担心将发送者强制转换为gridview然后使用它。

我觉得我必须在这里错过一个非常重要的设计考虑因素。我对我的代码做了些什么吗？我有点可以看到，使用直接引用这种方式成为全局对象的牺牲品，但这就是ASP.NET的工作原理！我在这里看不到什么？是否有一些精湛的书籍或教程，以“正确的方式”展示如何使用ASP.NET？干净，敏捷，“真正的编码器”方式？

Answer 1

您可能有一个DRY coding的事件处理程序，但有20个使用该事件的事情，例如：

protected void AddClass(object sender, EventArgs e) {
   ((WebControl)sender).CssClass += " myNewClass";
}

在这种情况下，您只需编写一次代码，但许多WebControl都可以使用它（这是一个例子，根本不是特定于WebControls。）

免责声明：我每天都使用sender吗？甚至没有关闭，它有用吗？是的，它可以是：）

Answer 2

是的，如果您有一个由多个控件调用的事件处理程序，并且您需要知道哪个控件称为事件处理程序。

这似乎是一种向后的方式，但如果事件处理程序对于大多数控件来说是相同的，它可以消除重复的代码，除了一些细微的差别。

那就是说，我曾经只在实际代码中见过它，我认为这会损害可读性。我喜欢每个控件/事件都有一个事件处理程序。

Answer 3

提供事件签名的sender参数，以便您可以建立事件的上下文。

这很有用，如果在ASP.NET控件层次结构中有多个嵌套控件，它们都为特定事件执行相同的事件处理程序，sender参数允许您区分不同的事件控制。

有时，子类EventArgs参数以更整洁的方式为您提供上下文，发送者对抽象事件处理程序仍然有用。

在ASP.NET中，是否有理由使用EventHandler的“sender”对象？

3 个答案: