First try at a ViewModel for the example

Article
02/27/2006

In the first iteration of this example, I databound the View directly to the Model. While not pretty, this was surprisingly functional. The list box was populated and when you changed selection through the list you automatically get a detail view of the selected item. However, the Add and Remove buttons did nothing, and in fact were always disabled.

At this point it would be easy enough to hook up event handlers to the ContactDatabaseChanged event and write some code to enable and disable the two buttons based on the state of the Model, then hook up event handlers to the Click events of each button that added and removed new items. However, by doing this you're already writing some general business logic in the view layer: the code that adds and removes things from the Model.

Instead, we introduce the ViewModel and then databind to that. Let's start with the public interface:

public class ContactDatabaseViewModel
{
// Methods
public ContactDatabaseViewModel(ContactDatabase model);

      // Properties
      public ICommand Add { get; }
      public CollectionView Contacts { get; }
      public ICommand Remove { get; }
}

The ViewModel takes the Model as a constructor parameter and wraps it. It provides Commands for the two operations we want, and exposes the list of Contacts through something called a CollectionView. More on CollectionView in a moment, but first here's the new XAML that binds to the ViewModel.

<ListBox x:Name="ContactsListBox"
Margin="12,12,11,94" RenderTransformOrigin="0.5,0.5"
ItemsSource="{Binding Path=Contacts}"

IsSynchronizedWithCurrentItem="True"/>

Remember that the View is now bound to the ViewModel rather than the Model, but the changes are very simple. The ListBox code looks exactly the same...it is bound to the Contacts property of the Model. Before that property was a List, now it is a CollectionView, but WPF databinding can handle them interchangeably. The Detail content control used to bind to the Items.CurrentItem of the ListBox through what WPF calls element to element databinding. Element to element databinding is quite powerful, but it does mean that you're hard-wiring coordination between parts of the UI into the View code. In the new code the ViewModel keeps track of the CurrentItem and we bind to that. In a simple example there is not much difference, but in a more complex UI all of the various controls bind to a central place, reducing the difficult to debug spaghetti dependencies between different parts of the UI code.

Finally, the two Buttons bind their Command properties to the two ICommands exposed from the ViewModel. Through the magic of the WPF databinding, you not only get the Buttons hooked up to the proper operations, you get their IsEnabled behavior for free.

I have attached the zip with the full running project. Download it, compare the old and new code and I'll discuss what this CollectionView thing is in my next post.

ContactViewModel1.zip

Comments

Anonymous
February 27, 2006
John Gossman has posted the first part of his long-awaited example of a Model-View-ModelView architecture,...
Anonymous
March 01, 2006
Could you give an example when Model-View-ViewModel doesn't work (not useful) ?
Anonymous
March 06, 2006
Good series! Keep it coming!

John
Anonymous
September 27, 2006
If you're doing WPF development, you really need to check out Dan Crevier 's series on DataModel-View-ViewModel.
Anonymous
August 08, 2008
PingBack from http://stefanleopold.wordpress.com/2008/08/08/viewmodel-commands/
Anonymous
January 13, 2009
Jag talar ofta med kunder och partners som vill använda vedertagna designmönster för att separera ansvaret

Share via

First try at a ViewModel for the example

Comments

Additional resources