在C＃中，事件重定向是一種好習慣嗎？ 如果為真，誰應該是“發送者”？

Question

現在，我正在重構其他人編寫的代碼，並且發現了一種對我的感受充滿困惑的構造。 有一個類似ListView的控件 ，它的每個項目都可以引發“ DialogOpened”事件。 但是，將外部事件處理程序注冊到每個項目可能很麻煩（並且可以動態添加或刪除這些項目！）。 因此，類似ListView的控件中只有一個事件，並將其命名為“ ItemDialogOpened”。 這對我來說聽起來很合理，但是有兩個問題：

1. 在類似ListView的控件中有一個方法'OnItemDialogOpened'引發單個事件，但是不會直接調用此方法。 而是將其注冊為每個項目的“ DialogOpened”事件的事件處理程序。 可以嗎 我問，因為我無法在MSDN中找到與之類似的東西。
2. 如果可以進行此類事件重定向，那么誰應該是那個最終的單個事件的發送者？ 現在，在我使用的代碼中，它是原始發件人-項目。 但是，我認為（但我不確定），現在應該將發送方更改為類似ListView的控件。 我對嗎？

Answer 1

對於2 -這是一個有點不同的解釋。 通常，您希望sender是您訂閱的東西； 其他任何信息都應通過args傳遞-但也有例外，例如（例如）單個商品作為sender通過。

重要的是要清楚地記錄下來。

Answer 2

對於1：此方法不能完全適合標准流型。 從我的角度來看，您必須在私有方法中隱藏自己的實現邏輯（此方法將成為每個項DialogOpened事件的終點 ），然后此方法將調用受保護的虛擬方法OnItemDialogOpened 。 在這種情況下，listview可以被繼承，通信邏輯將是透明的，並且更像ms，並且訂閱者將無需強制轉換即可工作（因為強制轉換隱藏在您的私有方法中）。 像這樣：

private void DialogOpenedHandler(object sender, EventArgs e)
{
    OnItemDialogOpened(new ItemEventArgs((YourItemClass)sender);
}

protected virtual OnItemDialogOpened(ItemEventArgs e)
{
    // call event here 
}