MVVM, MVP, MVC… which UI pattern should we use?

Which UI pattern should we implement in our application? I believe that the answer depends on the limitations of the technology that you are using (for example MVVM requires advanced data binding, which in the .NET framework is ready in WPF but not completely available in Winforms).

First let’s understand the different patterns:

There are a few interesting differences:

VIEW VIEW has a reference to VIEWMODEL
PRESENTER has a reference to VIEW and MODEL VIEWMODEL has a reference to MODEL

This structure defines how the objects are going to interact to each other and how the events will be propagated. Basically we have two kind of events:

  • Data events: this is when data changes in the model. In MVP they only arrive to the presenter, so it has the extra responsibility of updating explicitly the view with the new data, however in MVVM they are propagated until the view thanks to automatic binding
  • User events: this is when the user interacts with the user interface, maybe clicking a button or another control. In both patterns they arrive to the presenter/viewModel but in different ways, in MVP they are exposed in the IView interface and the presenter has to subscribe to them, however, in MVVM the viewModel just exposes Commands which are automatically binded to the controls in the view.

How to implement the patterns?

Let me explain it with a real example.

I have built an application called “Heart Rate Monitor” which shows the heart rate of a person. This is how the UI looks like:

The code is available in my GitHub repository:


The model is shared by both projects and it only contains a class which updates the heart rate with a random value every half a second:


The layout of both views is the same, they contain a textbox and two buttons:

And this is the code required to create the views:

As we can see, the Winforms solution requires a lot of code, in the other hand the WPF one doesn’t need any code at all and it just declares all the automatic binding in its XAML. Another problem with the Winforms design is that we are forced to create an interface (IHRMonitorView) which defines the exposed features that the presenter can see.

Presenter vs ViewModel

Having a look to the diagram at the beginning of the post, a presenter holds a reference to a view which is the only way to subscribe to its events. In the other hand, a viewModel doesn’t have any reference to the view because it is the responsibility of the view to forward its events to the viewModel using binding:

Another difference is that because the view in MVVM holds a reference to the viewModel, then it’s the responsibility of the viewModel to send notifications to the view everytime there are changes in the model which require rebinding. This is achieved using the INotifyPropertyChanged interface. As you can see, our viewModel inherits from a base class ViewModelBase which implements the interface so we can use the RaisePropertyChanged method to notify the view.


Having a look to both patterns, I would prefer to use the MVVM model because the flow of data feels more natural, directly from the model to the view using binding. It also doesn’t need an extra IView interface just to expose the features of the view to the presenter, which I believe doesn’t add to much value and seems a little bit of duplication. However, it’s not always our choice because we may work with a technology which doesn’t allow automatic binding like Winforms.

Also I would like to end this post talking about the MVC pattern. I believe that this is a very different pattern which cannot be compared directly with MVVM and MVP like we did here. The reason is that MVC fits more in the context of a web application where the user generates a request which is captured by a controller and then it’s the responsibility of the controller to choose and render a view specific to that request. It’s not really a pattern that we could use in a desktop environment and actually I believe that many times when people talk about MVC they are actually refering to MVP.

And of course, this is my personal interpretation of the patterns, I’m sure there will be other perspectives and explanations so maybe the best place to start a more accurate discussion is this Martin Fowler article about GUI architectures:

Leave a Reply

Your email address will not be published. Required fields are marked *