WP7 List Performance / ObservableMVMCollection

One of the key considerations when working with list data in the MVVM pattern is that the list should be represented by ViewModels, not Domain objects, except where the data to be displayed is very basic and contains no additional functionality.
The ObservableMVMCollection is a helper class that wraps a collection of Domain objects into a collection of ViewModels to assist with binding of list data, and this model works very well for its intended goal.

One of the details that was highlighted in the Tech Ed application however, was that the creation of fully implemented ViewModels is a non-trivial action when data is being loaded very quickly, and as the ViewModel creation occurs in the UI thread, this can cause unresponsiveness of the UI. In an effort to resolve this, I placed some of the logic into a background thread to reduce the overhead on the UI thread, which caused some issues of its own.

What I identified was a number of dependencies in the ExtendedViewModelBase that prevented the creation of ViewModel objects in a background thread, and ultimately this prevents us from offloading the viewmodel creation to a background thread. At the time I did not have a chance to delve too deeply into this, but I do have a few details where we can help resolve this issue. One area that looked to cause problems was the registering of MVVM Messages, but it is possible that the command creation could also be a problem in addition to others.

The first point I would like to make is that the ExtendedViewModelBase grew out of a need to provide common functionality between pages, and handles a number of common steps in the ViewModel lifecycle, as well as specific bindings and properties for common functionality (such as loading progress animations etc). However, when working with this list data, the actual functionality that these individual viewmodels need to present is severely limited. The most that would be required, in general, is to handle a few button or link events in the viewmodel, or to load some additional data not part of the domain object. All the additional functionality is really not required in these individual list item viewmodels.
In light of this, I think that we need at least two classes of Base ViewModel objects, ExtendedViewModelBase and LightViewModelBase in the framework, where the LightViewModelBase implementation is stripped back to a point where it can be generated quickly and efficiently, and more importantly instantiated fully on a background thread, where it can then be added to the appropriate ObservableMVMCollection on the dispatcher with no additional processing.

I believe this would go a long way to improving performance of an MVVM application, especially one with significant amounts of List data.