我们考虑使用Prism 事件聚合器来减少由于事件引用引起的内存泄漏。
这本身是使用这种模式的正当理由吗?其他好处现在对我们来说并不有趣。我们计划在模型组件而不是 UI 之间使用它。
我们的问题是一些开发人员忘记取消注册事件。我看到 Prism 有一种使用弱引用的风格,但它有局限性。另一种风格强制显式取消订阅(),这又可以被遗忘。那么如何更好呢?
我们考虑使用Prism 事件聚合器来减少由于事件引用引起的内存泄漏。
这本身是使用这种模式的正当理由吗?其他好处现在对我们来说并不有趣。我们计划在模型组件而不是 UI 之间使用它。
我们的问题是一些开发人员忘记取消注册事件。我看到 Prism 有一种使用弱引用的风格,但它有局限性。另一种风格强制显式取消订阅(),这又可以被遗忘。那么如何更好呢?
我们的问题是一些开发人员忘记取消注册事件
如果这是您的问题,切换到 Prism 事件聚合器(或使用任何其他实现)不会改善问题。
将具有新的、非平凡的使用模式的新依赖项添加到混乱的情况中根本不会整理它。
你需要的是清理你的代码。
我建议不要使用新的代码库,而是研究fxCop(又名代码分析)、Gendarme和NDepend等静态分析工具。所有这些都能够检测到一些事件没有被取消挂钩或 IDisposable 没有正确实现的情况。
使用静态分析,您可以冷静地识别需要清理的代码。使用内存分析器(如dotTrace Memory),您将能够找到最严重的违规者并及时清理它们。
回答以下评论中的问题:
您认为什么是确保事件脱钩的好模式?
很难确保所有事件都被取消订阅 - 但考虑到事件的实现方式(有关详细信息,请参阅CLR中的 CLR ),您可以通过确保丢弃所有事件订阅来作弊。
代替
public event EventHandler<Fu> FuBar;
自己处理事件订阅,如下所示:
public event EventHandler<Fu> FuBar {
add { mFuBar += value; }
remove { mFuBar -= value; }
}
private EventHandler<Fu> mFuBar;
然后,IDisposable
在您的类上实现,并在您的Dispose()
方法中设置mFuBar
为null
,丢弃订阅。FxCop(和其他工具)然后可以告诉您您是否未能 Dispose 类。