Bookmark and Share Share...    Subscribe to this feed Feed   About Christian Moser  

The Model-View-ViewModel Pattern

How the MVVM pattern became convenient

WPF has a very powerful databinding feature, that provides an easy one-way or two-way synchronization of properties. You can directly bind two WPF elements together, but the common use of databinding is to bind some kind of data to the view. This is done by using the DataContext property. Since the DataContext property is marked as inherited, it can be set on the root element of a view and it's value is inherited to all subjacent elements of the view.

One big limitation of using the DataContext property as data source is, that there is only one of it. But in a real life project you usually have more than one data object per view. So what can we do? The most obvious approach is to aggreate all data objects into one single object that exposes the aggregated data as properties and that can be bound to the DataContext. This object is called the view model.

Separation of logic and presentation

The MVVM pattern is so far only a convenient way to bind data to the view. But what about user actions, how are they handeld? The classic approach, known from WinForms is to register an event handler, that is implemented in the code-behind file of the view. Doing this has some disadvantages:

  • Having event handlers in the code-behind is bad for testing, since you cannot mock away the view.
  • Changing the design of the view often also requires changes in the code, since every element has it's different event handlers.
  • The logic is tightly bound to the view. It's not possible to reuse the logic in an other view
So the idea is to move the whole presentation logic to the view model by using another feature of WPF, namely Commands. Commands can be bound like data and are supported by many elements as buttons, togglebuttons, menuitems, checkboxes and inputbindings. The goal here is not to have any line of logic in the code-behind of a view. This brings you the following advantages
  • The view-model can easily be tested by using standard unit-tests (instead of UI-testing)
  • The view can be redesigned without changing the viewmodel, because the interface stays the same.
  • The view-model can even be reused, in sone special cases (this is usually not recommended)

What's the difference between MVVM, MVP and MVC?

There is always some confusion about the differences between model-view-presenter, model-view-controller an MVVM pattern. So I try to define and distinguish them a bit more clearly.

MVC - Model-View-Controller

The MVC pattern consists of one controller that directly gets all user input. Depending of the kind of input, he shows up a different view or modifies the data in the model. The model and the view are created by the controller. The view only knows about the model, but the model does not know about any other objects. The pattern was often used in good old MFC and now in ASP.NET MVC

MVP - Model-View-Presenter

In the MVP pattern, the view gets the user input and forwards it to the presenter. The presenter than modifies the view or the model depending on the type of user action. The view and the presenter are tightly coupled. There is a bidirectional one-to-one relation between them. The model does not know about the presenter. The view itself is passive, thats why it's called presenter pattern, since the presenter pushes the data into the view. This pattern is often seen in WinForms and early WPF applications.

MVVM - Model-View-ViewModel

The model-view-viewmodel is a typically WPF pattern. It consists of a view, that gets all the user input and forwards it to the viewmodel, typically by using commands. The view actively pulls the data from the viewmodel by using databinding. The model does not know about the view model.

Also check out this interesting article from Costas Bakopanos, a friend of mine, a discussion about the model, states and controllers in the MVVM environment.

Some MVVM Frameworks

Check out this handy tool to compare MVVM frameworks: MVVM Comparison Tool (Silverlight

Last modified: 2011-02-07 16:15:46
Copyright (c) by Christian Moser, 2011.

 Comments on this article

Show all comments
Commented on 4.February 2011
Hi Christian, check out Jeremy's new article:
Commented on 4.February 2011
what is MVVVM? or is that a typo in:
What's the difference between MVVVM, MVP and MVC?
Christian Moser
Commented on 7.February 2011
Hi John. It was a typo. I corrected it. Thanks.
Commented on 24.February 2011
Nice Give Some examples
Commented on 3.March 2011
Hey, great article. Shouldn't the arrow on the MVC picture go from the view to the model? Cheers
Commented on 14.March 2011
Hey. Its nice article
Commented on 16.March 2011
Yes, I agree Michal, the arrow should point from the view to the model.
Commented on 21.March 2011
The description about the MVC pattern says "The view only knows about the model, but the model does not know about any other objects." The graph, on the other hand, depicts a model that knows about the view, and a view that doesn't know about any other objects. The vertical arrow should be reversed.

Also, in the MVP pattern, why can there be only one view? I can well imagine scenarios with more than one view, all coupled to the same presenter, same as when the MVC pattern has more than one view.
Commented on 24.March 2011
this stuff became very helpful in my life..thanks a lot christian.
Commented on 11.April 2011
nice diagram. great article!
Commented on 11.April 2011
Tanx #
Arie Baba
Commented on 13.April 2011
Thanx dude. This is one of the best pattern explanations I've ever seen.
Commented on 20.April 2011
Explain why is the flow in the MVVM diagram showing a V->VM->M, when the name suggests M->V->VM
Commented on 6.May 2011
It was named to keep it's name in line with the other MV patterns. Not to specify the flow of the data itself.
MV Controller
MV Presenter
MV ViewModel
Commented on 15.May 2011
I have a few questions to MVVM:
1. Can VM contains any business logic? Or should it be delegated to Model?
2. Can I put code responsible for saving entity in VM? Or also saving process should be delegated to some external class?I use Entityy Framework and I have context which saves entity. Can I put that code in VM?
Rajneesh Verma
Commented on 1.June 2011
Hi, Christian I found one small grametical mistake please correct it. Its here
â¢The view-model can even be reused, in sone special cases (this is usually not recommended)
sone should be some.
Thanks for nice explanation.........
Satya Dev
Commented on 3.June 2011
Answers to Peter's Questions

1. Don't put business logic in the view model(VM). Think of VM as a surrogate for View (V). Since it is hard to test the UI components (like Buttons, Lists etc.) using automated tests, we are creating VM objects. Think of VM as UI with visibility

2. Again I recommend delegating saving of data to a Service class
Commented on 6.June 2011
Hy Christian! Thanks a lot for this tutorial. It's fantastic ;) !
Commented on 15.June 2011
Great Article. But the Arrow should point from View to Model in MVC as model normally does not know anybody else.
Commented on 29.June 2011
Great Article, it would be great if you attach some samples to explain them. i mean samples with UI and DataBinding.
Commented on 1.July 2011
Thanks Christian, your material got me up and running with wpf in a few hours.
Umesh .A Bhat
Commented on 26.July 2011
Thank you Christian, Good Article. Gets me started on WPF MVVM.
Commented on 27.July 2011
Article is great. One small query in MVC you have mentioned that controller gets the input from user...Pagehandlerfactory class you mean to say? could you please explain in terms of .aspx page...user access applicatioj by hitting url.
Commented on 28.July 2011
Can u plz share some code snippet on this section
Commented on 30.July 2011
I agree with Frodo. Please spellcheck your article next time before posting. It contains typos and grammar mistakes which are distracting while reading it.

E-Mail (optional)