Cleanup vs Dispose(bool) in MVVM-light

In the latest version of MVVM-light (V3 SP1) both "Dispose()" and "Dispose(bool)" methods in ViewModel class are marked

Do not use this method anymore, it will be removed in a fu开发者_如何学Goture version. Use ICleanup.Cleanup() instead

Does this mean that IDisposable interface must not be implemented in all ViewModel classes that are derived from GalaSoft.MvvmLight.ViewModelBase (and cleanup must be overrided)?

If yes, using can't be used for view-model instances... Probably I didn't understand something... Please clarify... What are the benefits of such cleaning up?

Thanks.

---

The issue is historical. At first I thought it would be a good idea to force all VMs to be IDisposable. However, IDisposable has a different intent: Once the VM is Disposed, it is expected (by convention) that it will be garbage collected as soon as possible. After talking to friends, I realize that forcing all VMs to be IDisposable was a mistake. This is why I replaced IDisposable by ICleanup. The intent of ICleanup is to provide a way to clean VMs (for example flushing their state to persistent storage, closing streams etc...) but not necessarily in a way that they will be garbage collected as soon as possible.

Nothing prevents you to make your VMs implement IDisposable. I just didn't want to keep this constraint in the ViewModelBase class, which is why this interface will be removed in V4.

The benefit of having ICleanup is that you can clean all your VMs in one call of ViewModelLocator.Cleanup(). It is a hint to VM developers saying that VMs should think of providing a cleanup method for their VMs.

Does that make sense? Cheers, Laurent

---

"Interesting" little story: having found programmers on my team had not been unsubscribing from events, I 'washed' IDisposable down our view model hierarchy only to change my mind about whether Dispose was the right place.

In some circumstances, it was hard to call Dispose because of MEF and some other funky ways we create our view models. This made me wonder if it was right. And then there's the fact that Dispose needs some care (and a snippet) to get right:

DG Update: Dispose, Finalization, and Resource Management

Later, I did some weekend work on a WP7 app (where I use MVVM Light) and noticed Laurent's change of heart, too.

I think its the right decision; IDisposable sends a message that the "customer" should try and wrap the class usage in a using() or otherwise wash their hands of the instance ASAP.

Originally, I agreed with the accepted answer in the thread below but then I started to think JaredPar was right.

Using IDisposable to unsubscribe events

Luke

---

I think I beg to differ somewhat with Laurent on this point. The idea behind IDisposable is that the object may have some cleanup that needs to take place and does not, per se, have anything to do with garbage collection. In fact, most of the time IDisposable is implemented in order to clean up unmanaged resources, such as file handles, sync objects or database connections, which are outside the purview of the GC. Besides, just because a base class implements IDisposable doesn't mean it has to have an actual implementation. That's can be relegated to the virtual Dispose(bool disposing) method that can be overriden by derived classes so they can perform cleanup.

The issue, as Budda alludes to, is that IDisposable is by convention a one-way operation. Once an object has been disposed, it should throw an ObjectDisposedException on its public methods. If all you want to do is flush out resources so that you can reuse the object, then a Cleanup method makes sense. However, I would not necessarily remove the Dispose functionality, which serves a different purpose.