在mvvm灯中清除与处置(bool)

这个问题是历史性的。起初,我认为强制所有虚拟机都可以IDisposable是个好主意。但是,IDisposable有一个不同的意图:一旦VM被释放,它(按照约定)将尽快被垃圾收集。在和朋友交谈之后,我意识到强迫所有虚拟机都可以识别是一个错误。这就是为什么我用icleanup替换了idisposable。icleanup的目的是提供一种清理虚拟机的方法(例如,将其状态刷新到持久存储、关闭流等),但不一定以一种尽快将其垃圾收集的方式。

没有什么能阻止您使您的虚拟机实现IDisposable。我只是不想在ViewModelBase类中保留这个约束,这就是为什么这个接口将在v4中被删除的原因。

使用icleanup的好处是,可以在一次调用viewModelLocator.cleanup()中清理所有虚拟机。这是对虚拟机开发人员的一个提示,他们认为虚拟机应该考虑为他们的虚拟机提供一个清理方法。

这有道理吗? 干杯, 劳伦特

我想我在这一点上与劳伦特有些不同。IDisposable背后的想法是,对象可能需要进行一些清理,而本身与垃圾收集没有任何关系。事实上,大多数时候IDisposable是为了清理 非受管的 资源,如文件句柄、同步对象或数据库连接,它们不在GC的权限范围内。此外,仅仅因为基类实现IDisposable并不意味着它必须有实际的实现。这可以降级为虚拟释放(bool disposing)方法,该方法可以被派生类重写,以便它们执行清理。

正如Budda所暗示的,问题在于idisposable通常是单向操作。一旦对象被释放,它应该在其公共方法上抛出一个objectDisposedException。如果您只想清除资源以便重用对象,那么清理方法是有意义的。但是,我不一定要删除Dispose功能,它有不同的用途。

“有趣的”小故事:在我的团队中发现程序员没有退订事件,我“清洗”了视图模型层次结构中的IDisposable,只是为了改变我对Dispose是否是正确位置的看法。

在某些情况下,很难调用Dispose,因为MEF和其他一些我们创建视图模型的时髦方法。这让我怀疑这是否正确。还有一个事实是,Dispose需要一些注意(和一个片段)才能正确处理:

DG Update: Dispose, Finalization, and Resource Management

后来,我在一个wp7应用上做了一些周末的工作(我在那里使用mvvm-light),也注意到了劳伦特的心脏变化。

我认为这是正确的决定;IDisposable发送一条消息,“客户”应该尝试将类的用法包装在using()中,或者尽快洗手。

起初,我同意下面的答案,但后来我开始认为贾雷德帕是对的。

Using IDisposable to unsubscribe events

卢克