MVC, MVP & MVVM

MVC, MVVM, MVP

I decided to get to the bottom of these patterns and what the differences are. The most common motivation behind these patterns are the cross cutting of concerns, swapping out the user interfaces (i.e. windows for web) and of ease of unit testing.

Figure 1. MVC

In this pattern the controller has no reference to the view. Therefore we can swap out controllers and use the same controller for multiple views. The idea is the Controller handles events from the View, then manipulates the Model which raises events that cause the UI to update its own state.

Figure 2. MVP

Again three components but the dependencies change. Here the Presenter takes the onus to manipulate the model but also updates the view. The reference between the presenter and view is direct, as it knows about the view and makes changes on it.

Figure 3. MVVM

Introducing the ViewModel. Here we have replaced the Presenter with the View model. This pattern is really quite similar to the MVP pattern however there is one key difference. The relationship between the View and ViewModel is indirect. The View knows about the ViewModel, but the reverse is false. The result – clear cross cutting of concerns the View takes responsibility of how it looks where as the ViewModel takes responsibility of what data is displayed to the UI.

In the world of WPF the relationship between the View and ViewModel ideally should occur like this. View to ViewModel – the direction of this relationship should be governed by WPF Commands. ViewModel to View – the direction of this relationship is achieved by DataBinding via WPF dependency properties.

Anyway glad I got to the bottom of that!