5 Minute Overview of MVVM in Silverlight

Model-View-ViewModel (better known by its super hero alias of MVVM ) is a great pattern to use with Silverlight and WPF. Here is my 5 minute perspective on MVVM (yep, it took me 5 minutes to spit this out too, so please be kind on any typos :-) )

One of the things that can be frustrating with any pattern is the immediate assumption that many articles have that everyone knows what MVVM means. This post is intended to be a short, quick, and hopefully easy explanation of MVVM. Another interesting aspect of MVVM is that you can find many ways of actually using MVVM. I will point out some of the differing opinions as I move along. Not all of them, but a few just to give you an idea of what you might see out there. This post assumes the technology is Silverlight or WPF.

This explanation is intended to give an overview on the roles of View, Model and ViewModel. The graphic at the bottom shows the basic association between the MVVM triad. There are different ways to handle some aspects of MVVM. But the element between them all is the singular purpose behind the View, the Model, and the ViewModel.

In a future post I will explain in more detail how I implement MVVM, why I chose the way I do it, and some of the pros and cons.

Why?

1 reason MVVM works really well with XAML based applications is because of the powerful XAML binding features. This allows the View (the presentation of to the user) to be separated from the data and the logic. The View can be designed in Expression Blend while the ViewModel can be developed in Visual Studio .NET. It allows for the presentation to be separated very easily. This is just 1 reason, albeit a powerful one.

View

A View is a class that represents the user interface that the user will see. In Silverlight this is the MainPage.xaml or Page.xaml class, for example. The View contains the visual controls that will be shown to the user and can also contain animations, navigation aspects, themes, and other interactive features for the purpose of the visual presentation. In Silverlight and WPF the View also contains binding extensions that identify the data points that will be presented to the user (embedded in XAML). The bindings point to the names of the data point properties, but do not have awareness of where those properties are nor where they come from. The bindings are activated when the View’s DataContext is set to a class that contains the source for the bindings.

Differing Opinions:

Some people create a View and assign it a source for its data right in the View. This can be done by creating a resource in the XAML that points to a ViewModel. I prefer to associate my View and ViewModel separate from each other so they are not coupled. however it is very common to see the ViewModel created inside the View as a resource. Either way is good. Creating it inside the View is easier and can allow for more fun when using Blend. Associating the ViewModel and the View through another class is looser and can allow for more DI and testability. Again, both are good and prominent in the wild.

Model

A class that represents data points describing a specific entity.  For example, a Customer class with properties such as CompanyName and CustomerId. The Model can contains child Model’s too, like any object graph. So a Customer Model can contain a property named Orders which is a set of Order Models. The Model’s purpose is to represent the data points and it has no knowledge of where it will be presented to a user nor how it will be presented. It’s single responsibility is to represent the data points.

Differring opinions:

Some people create the Model and give it awareness of where it comes from. I do not take this approach as I like to keep the Model ignorant of this and loosely coupled from where it comes form. However to offer up one different way to handle this it could help to discuss this at a high level. Some make the Model also have awareness of how to load and save itself (persistence awareness). For example, this could mean it knows how to call a web service to do this. Again, I do not do this. Rather I prefer to make that saving and loading of a Model happen in another class which has the single responsibility of handling these aspects.

ViewModel

The ViewModel is the glue between the View and the outside world. The ViewModel is what the View is bound to. The View’s DataContext is set to an instance of a ViewModel class. This is where all of the bindings declared in the View’s XAML The ViewModel contains the Model, so it has all of the data points needed in many cases right there. The ViewModel also can declare public properties for Commands (ways to invoke actions from the View to the ViewModel) and other properties that can be bound to the View.

Differing Opinions:

In my architecture, my ViewModel classes make calls to another class that handles filling the Model(s) contained within the ViewModel. Some other ways of doing this are to simply have the ViewModel go get the data himself. Again, I lean towards keeping my classes focused on a single responsibility so my examples generally do not do that. Instead, I have a class that is in charge of hitting a web service to go and get my data and fill my Model for my ViewModel.

Common Picture of the MVVM Triad

I hope this helps!