Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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 future 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.

like image 559
Budda Avatar asked Jun 03 '10 03:06

Budda


3 Answers

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

like image 102
LBugnion Avatar answered Nov 13 '22 08:11

LBugnion


"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

like image 43
Luke Puplett Avatar answered Nov 13 '22 07:11

Luke Puplett


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.

like image 2
Anthony Sneed Avatar answered Nov 13 '22 06:11

Anthony Sneed