WeakReference and event handling

吃可爱长大的小学妹 提交于 2019-11-28 20:13:16

It is good to get in the habit of unsubscribing from events when you can, but sometimes there isn't an obvious "cleanup" method where it can be done. We recently posted a blog article on this subject; it includes methods that make it easy to subscribe to an event with a WeakReference.

Weak delegate pattern is something that should be there in CLR. Normal events exhibit "notify me while you are alive" semantics, while often we need "notify me while I'm alive". Just having delegate on WeakReference is wrong, because delegate is an object too and even when recepient is still alive and have incoming references, delegate itself is only being referenced by said WeakReference and will be collected instantly. See this old post for an example of implementation.

Weak references in their own right, don't solve the problem as the delegate holds the reference. In the Composite Application Library which ships with Prism (www.microsoft.com/compositewpf) there is a WeakDelegate class that you could pull from the source. The WeakDelegate basically ues reflection and creates a delegate only for a moment in time and then releases it, thereby no holding any pointers. Within CAL it is used by the EventAggregator class, but you are free to rip it out for your own usage as it is under MS-PL.

While what you suggest solves one set of problems (event reference management and memory leak prevention), it is likely to open up a new set of problems.

One problem I can see is during event handling process if the source object is garbage collected (as it was only held with a weak reference), any code that access the source object will result in null reference exception. You can argue that the event handler should either not access the source object or it must have a strong reference, but it can be argued that this could be a worse problem than the one you are trying to solve in the first place.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!