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

在做很多ASP.NET页面（.NET 2.0）时，我的代码隐藏通常与页面对象上的事件处理程序一起打包。 GridView_RowCommand，Button_Click等所有常见的嫌疑犯。所有EventHandler派生的东西都有一个共同点，那就是它们的第一个参数是一个对象，通常标记为“发件人”。在ASP.NET中，是否有使用EventHandler的“sender”对象的理由？

在ASP.NET代码隐藏中，我真的没有看到它的重点。如果我有GridCustomers_RowCommand，并且需要为GridCustomers做些什么，我可以从代码隐藏中访问它，而不用担心将发件人投射到GridView然后使用它。

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

来源

2010-08-05 CodexArcanum

也许你有一个DRY coding事件处理程序，但使用该事件的20件事，例如：

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

在这种情况下，你一旦写代码，但它可以通过多种器WebControls使用（这是一个例子，根本不是特定于WebControls的）。

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

来源

2010-08-05 15:30:45

有了额外的免责声明，我认为这是一个非常好的综合答案。我没有考虑过使用它的多个控件的情况，但是对于像gridview或中继器那样，这可能非常方便。另外，我很高兴知道我不是唯一直接使用控件名称的人！我现在感觉好多了。 – CodexArcanum 2010-08-05 16:00:31

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

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

这就是说，我只有一次在真实代码中看过它，而且我认为它伤害了可读性。我喜欢每个控件/事件都有一个事件处理程序。

来源

2010-08-05 15:30:11 David

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

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

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

来源

2010-08-05 15:35:03 Rabid

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

回答

相关问题