Do not use ObservableCollection<T>

Update Controls not only implements INotifyPropertyChanged for you, it also makes all of your collections observable. When you use Update Controls, you should not also use ObservableCollection<T>. Use a regular List<T> instead.

Define a property of type List<T> in your data model. Select this property and hit Ctrl+D, G. This code will be generated for you:

public class ContactList
    private List<Person> _people = new List<Person>();

    #region Independent properties
    // Generated by Update Controls --------------------------------
    private Independent _indPeople = new Independent();

    public Person NewPerson()
        Person person = new Person();
        return person;

    public void DeletePerson(Person person)

    public IEnumerable<Person> People
        get { _indPeople.OnGet(); return _people; }
    // End generated code --------------------------------

The Independent property is notified every time the collection changes (NewPerson and DeletePerson). It is also notified every time the collection is modified (the People getter). This is all happening in the data model.

The view model does not store a list. It only has a reference to the data model. Using this reference, it generates a collection of view models on the fly.

public IEnumerable<PersonViewModel> People
        return _contactList.People
            .Select(p => PersonViewModel.Wrap(p, _contactList));

Where PersonViewModel.Wrap looks like this:

public static PersonViewModel Wrap(Person person, ContactList contactList)
    if (person == null)
        return null;
        return new PersonViewModel(person, contactList);

This is much easier than managing ObservableCollections. You don't need an intermediate collection. You just wrap your data objects in a view model on the fly.

For more information, please see the example of using Linq to replace ObservableCollection<T>.



If the list is large, adding or removing a person causes a refresh of the whole list, with new view-models created for every item, is that right? I'm curious if there is a more efficient approach for very large lists... well, actually in my case, I'm considering porting Update Controls to .NET Compact Framework (WinForms). Lists would be only moderately large (up to 1000 items), but refreshing a ListBox from scratch is likely to be quite slow.


Internally, Update Controls is using object recycling. Every PersonViewModel from the prior run is put into a recycle bin before the People property is called. Then it looks for each PersonViewModel that you return in the recycle bin. If it's already there, then it reuses that one.

What I neglected to say in the article is that you should implement Equals and GetHashCode on PersonViewModel. That will make it possible for the recycle bin to find the matching object. Two PersonViewModel objects are equal if they reference the same Person.

So, yes, you are creating a new batch of PersonViewModel objects every time the Person property is updated. But the ones that are already bound to the UI are reused. That means that the ListBox items themselves are not destroyed and recreated, which would be the real performance hit. Not to mention, that would reset the scrollbar position.

I've used Update Controls for lists about that size without a noticeable performance problem. But if you go much larger I'd recommend doing something different. Beyond a couple of thousand you start to run into memory pressure from all of the internal dependency tracking. Memory might be your chief concern on the compact framework.

Let me know if you decide to take on the port.