design patterns - One sentence explanation to MVVM in WPF?

Question

I heard its the next best thing in building WPF UIs, but all existing examples have dozens of lines of code - can I get a Hello World for MVVM that explains in no uncertain terms what its all about? I'm fairly new to C#/.net as well, so maybe point me to some resources that could help too?

Much appreciated!

Answer 1

One sentence explanation:

MVVM is a reimagining of the well loved Model-View-Presenter (MVP) pattern that is designed to work especially well with databinding facilities supplied with WPF to separate application logic from UI design.

Longer, more useful, explanation:

The basic concept of MVVM is the break apart a WPF application into separate components each of which has one responsibility in the process of getting information on screen.

Firstly you have the model. This is a class with very limited functionality that is generally populated from some outside source such as a database or webservice. For example:

public class MessageModel
{
    public string Message { get; set; }
}

On top of that you layer the ViewModel, this is where the logic of the application sits, it notifies the view of changes to the model and ensures data consistency. By implementing the INotifyPropertyChanged interface two way databinding between the ViewModel and the view is given for free by WPF:

public class MessageViewModel : INotifyPropertyChanged
{
     private MessageModel _model;

     public string Message
     {
          get { return _model.Message; }
          set
          {
              if (_model.Message != value)
              {
                  _model.Message = value;
                  OnPropertyChanged("Message");
              }
          }
     }
}

Finally you have the View. This is a xaml file that describes the layout of the controls used to display and edit the data in the ViewModel:

<Canvas>
     <TextBox Text={"Binding Message"} />
</Canvas>

The reason that you go to all this effort is that the Model is very lightweight and easily passed across domain boundaries. It is simple to send or receive it from a webservice or map it to a database table. The ViewModel, on the other hand is complex, but has few dependencies - it doesn't care where the model gets it's data from, only that it is there and it has no concept of a view at all which makes it very testable (the logic of your application doesn't rely on a UI to test). Finally the xaml is well compartmentalised and can be handed off to a designer who needs to know nothing about the logic of the application, only that the ViewModel will present certain data under certain names. This encapsulation makes it very easy to define roles in large projects, or put together a limited UI to test logic against while the real one is being polished.