何時使用弱事件？

Question

我在弱事件上引用了MSDN教程。 我理解基礎知識。 我正在開發一個非WPF項目，我的課程正在暴露某些事件。 我的問題是弱事件是否完全取代舊的事件模式？ 每個暴露事件的類都使用它是否好？ 大量使用弱事件的副作用是什么？

Answer 1

根據我所做的閱讀，使用WeakEvents似乎沒有任何具體的負面影響，除了事實上這樣做更加冗長。 此外，在大多數情況下，您應該能夠在不再需要時從事件中手動取消注冊。 在某些情況下，這是不可能的。 例如，您引用的MSDN頁面應該在您應該使用WeakEvents時提及：

http://msdn.microsoft.com/en-us/library/aa970850.aspx

某些場景固有地適用於弱事件模式的應用。 一種這樣的場景是數據綁定。 在數據綁定中，源對象通常完全獨立於偵聽器對象，偵聽器對象是綁定的目標。 WPF數據綁定的許多方面已經在事件的實現方式中應用了弱事件模式。

唯一一個向他們提出任何負面影響的人就是這個博客：

http://blog.catenalogic.com/post/2011/11/23/A-weak-event-listener-for-WPF-Silverlight-and-Windows-Phone-7.aspx

一般來說，使用弱事件偵聽器有一些缺點：

• 它的符號很難看，“原始”的.NET方式看起來更好
• 你必須用字符串命名事件，這很糟糕（如果你知道更好的方法，請聯系我！）
• 它只能使用EventHandler的處理程序處理事件
• 你成為一個懶惰的開發人員，不關心訂閱

從本質上講，它們應該用於您的對象在其存在的整個長度內訂閱的事件，並且僅在對象被處置時斷開連接。 對於其他所有內容，首選使用傳統事件並手動注冊/取消注冊事件。

Answer 2

弱事件必須考慮兩個問題：

1. 弱事件允許訂閱者訂閱事件（消息），甚至不知道引發事件的類的身份。 在某些情況下甚至可能需要。 但是，在某些情況下，可能會引入不必要的復雜性和間接性，從而使代碼在運行時更難以管理或控制。
2. 使用弱事件的主要缺點是它可能會鼓勵開發人員忽略他們取消訂閱事件（消息）的部分。 在這種情況下，即使在訂閱者“超出范圍”之后也可以調用事件處理程序。 考慮一個沒有明確取消訂閱的訂閱者，該訂閱者可以收集垃圾，但尚未收集垃圾。 弱事件管理器將無法檢測到該狀態，因此它仍將調用該訂戶的事件處理程序。 這可能會導致各種意想不到的副作用。

在弱事件模式中看到更多細節是危險的 。
請參閱此源代碼 ，該代碼使用MvvMCross消息傳遞插件作為弱事件管理器來說明此問題。

Answer 3

什么時候使用弱事件？

來自MSDN

偵聽事件可能會導致內存泄漏

所以你應該使用弱事件來避免這些泄漏

每個暴露事件的類都使用它是否好？ 大量使用弱事件的副作用是什么？

請參閱為什么C＃中的事件實現默認情況下不使用弱事件模式？ 。 從“強”事件中泄漏並非通常情況，弱事件伴隨着性能成本並且具有在每種情況下可能都不需要的語義差異，濫用弱參考可能導致事件間歇性地不發射（與之相反）濫用導致內存泄漏的正常事件）

可以避免的內存泄漏示例

靜態類和單身人士在討論內存泄漏時是壞人，當他們獲得對其他對象的引用時，他們將阻止對象被垃圾收集，從而在應用程序的生命周期內泄漏對象， 這是我遇到的一個例子需要弱引用以避免內存泄漏

Answer 4

首先，弱事件並不總是必要的，就像其他人一直說的那樣，只有當源對象比訂戶更長時。 如果是這種情況，那么是的，你應該使用它，這就是人們所說的弱事件模式 。

副作用只是你必須編寫更多的代碼。 Microsoft提供了WeakEventManager類，並且在WPF中存在一些特定的實現，但是您可以創建自己繼承自WeakEventManager的基礎。

它的工作方式是使用從源對象到偵聽器的弱引用 ，因此這種關系不會阻止GC收集這些對象。 對於某些特定應用程序，這可以解決許多性能問題。