views:

842

answers:

2

I'm working on a Silverlight app using the MVVM pattern. My ViewModel currently consists of a property that represents a collection of Model Objects:

public ObservableCollection<IndexEntry> IndexList
     {
      get;
      set;
     }

it also has several methods that will populate that collection with data that comes back from a webservice.

Since instances of this class may be created and destroyed over the course of the application runtime, should I implement IDisposable and set the property's reference to null or will the destruction of this class be sufficient to remove all references to the collection tis property refers to? Are there any caveats that might leave a reference hanging out there?

Thanks.

+5  A: 

The only way a reference survives garbage collection is if it is rooted. If there is some other class that is still in use that contains a reference to the ObservableCollection, then the ObservableCollection will not be destroyed, regardless of whether or not you set it to null. For example, suppose there is one 'in memory' object that is your collection. You have one reference to it, in your property. Some other code executes the line "ObservableCollection<> myOtherReference = YourObject.IndexList;". They now have a reference to the actual memory object, too. Making your property reference null will only eliminate your property's reference; the 'myOtherReference' reference is unaffected, as it is now pointing at the memory directly, and not at your property. If you really want to eliminate this item from memory, you need to remove ALL the references, or implement some decisive 'dispose' logic, at which point "myOtherReference" would be a pointer to a disposed object, and any call to it will throw an exception.

GWLlosa
Thanks much. This makes sense. I was trying to use IDisposable to make certain that all hanging references would be removed, but clearly that won't work.
Steve Brouillard
+2  A: 

GWLlosa is spot on. In addition, Silverlight data binding will keep your ViewModel pinned as long as you have a Binding reference to it. In other words, you’ll either need to remove your ViewModel from the DataContext of the view (by setting View.DataContext=null) or your view will need to be removed from the visual tree before your ViewModel is released. Implementing IDisposable won’t help and I wouldn’t really recommend it for this. IDisposable is intended for cleaning up unmanaged resources or for having more control over your managed resource disposal. It’s not necessary in this case if you properly understand how bindings and references work and just let the garbage collector take care of things. This article could help:

Finding Memory Leaks in WPF Applications

It’s primarily WPF but you can use the techniques on Silverlight too.

Cool to see you using ViewModel by the way. I’m a big fan of the pattern.

Jared Bienz - MSFT
Jared, Thanks for the reminder on the binding issue. I'm becoming a big fan of the pattern as well. Just takes a bit to get your head around as it isn't a linear an approach.
Steve Brouillard
Indeed. It is very convenient to let the framework take care of things like data rountripping, but not owning the code makes it easy to forget about how it's managed. Some cool things are on the way in this space in the next few months. Keep an eye out and have fun!
Jared Bienz - MSFT