在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」對象的理由？

回答

相關問題