MVC vs. MVP vs. MVVM

An important FAQ. The answer actually depends on where the person is coming from. MVC is a fundamental pattern which has been tweaked quite a bit to fit into various platforms. For instance if you had asked anybody how to implement an MVC in ASP.NET (prior to release of ASP.NET MVC framework) you would get very different answers. So let’s start with basic. The common motivation behind all three is separation of concerns – cutting flab from UI (good for UI designers), swapping UIs (for instance windows to web), make UI conducive to Unit Testing, etc. Have a look at the below diagram, I have taken it from CAB documentation. Let’s dig into them.


MVC: Three components – View (your UI), Model (your business entities / data – that view is displaying) & Controller (contains the logic that alters the model state depending on the action triggered by UI – typically implementing a Use Case). It’s widely known that MVC is a compound design pattern (View and Controller have Strategy design pattern implementation, View itself can be a Composite pattern implementation & View and Model are synched through Observer pattern; for more details refer to GOF patterns). In MVC, Controller doesn’t know anything about View, and the idea is that a View can switch Controllers (for instance depending upon who has logged to the system) & a single controller can be used by multiple Views. View subscribes to the changes done to the model & hence both are sync from the state perspective. One of the disadvantages of MVC is that it’s difficult to unit test. Controller manipulates the data but how about asserting those changes from a view perspective. For instance, on click of a button you raise an event to controller, controller modifies the value in model, and this model state modification changes the font size / color in View. Unit testing this scenario is slightly difficult in MVC.

MVP: Again three components but the dependencies change (look at arrows in the above diagram). Over here we replace Controller with Presenter (one which presents the changes done in model back to view). The main difference between both is that in MVP Presenter refers back to the view while in MVC the Controller doesn’t. Normal pattern found here is to create a mock for the View (in terms of properties / events) & Presenter is injected with it. This makes the testing of View much easier & hence the Unit Testing aspect. Presenter here hence takes the responsibility of not only manipulating model but also updating the view. Of course, the implementations of MVP differ in real world in terms of complexity of the view. Some prefer keeping basic logic still inside view & taking complex logic in presenter, while others prefer keeping the entire logic in Presenter. Martin fowler describes 2 variations on MVP on these lines namely – Supervising Controller & Passive View described below.

A Passive View handles this by reducing the behavior of the UI components to the absolute minimum by using a controller that not just handles responses to user events, but also does all the updating of the view. This allows testing to be focused on the controller with little risk of problems in the view.

Supervising Controller uses a controller both to handle input response but also to manipulate the view to handle more complex view logic. It leaves simple view behavior to the declarative system, intervening only when effects are needed that are beyond what can be achieved declaratively.

MVVM: Model–View-ViewModel talks of creating a new model (in addition to your domain model). This model has fields and properties from the perspective of View typically a superset of domain model (as we understand that View has more data points in addition to model state being displayed). For instance, if View has a property IsChecked and Presenter was setting in classic MVP, in MVVM Presenter will have that IsChecked Property which View will sync up with (doesn’t it look like Strategy pattern has been replaced with Observer pattern 🙂 ?). So now a Presenter becomes more like a combo of – View Properties & Model properties which would be synchronized with View. So why not rename Presenter to ViewModel? Do that and you get MVVM (replacing ‘P’ with ‘VM’ in MVP). MVVM is attractive for platforms which support bi-directional view-model binding reducing the implementation effort. Also a minor tradeoff is ViewModel unlike Presenter can stand on its own for unit testing (Presenter normally requires a View’s interface). Martin fowler describes similar pattern called Presentation Model & Josh Smith captures MVVM implementation for WPF / Silverlight in this article.


ASP.NET MVC: So what has MVC got to do with ASP.NET MVC? First, Web application work on a different model. Here, user interacts with HTML in browser and send a request back to the server for processing (for client side Ajax you might go just for data). As the interaction is normally stateless, when the request comes back to the server we need to recreate our View, load the model back & manipulate both of them as required. There are 2 variations on how handle this recreation – Page Controller & Front Controller. Page Controller makes Page the decision maker – in this widely implemented pattern HTTP request is sent to specific to physical page on server (.aspx for instance) & the page in turn creates itself (builds the view from postback data), triggers the state manipulation (events in codebehind file) and model changes are made. As you see here, the distinction between View & Controller becomes blur & is little difficult to separate. This where ASP.NET MVC comes in. It behaves like a Front Controller – where Controller is the decision maker. Here all HTTP requests are mapped to methods on the Controller Class. Controller class recreates the model & view as required and does the manipulations. This makes unit testing easier as we can directly instantiate the front controller class & invoke methods on it to perform the assertions.

I can add code snippets to above explanations if you feel they would help you understand things better. I will look forward to your comments 🙂 .

79 thoughts on “MVC vs. MVP vs. MVVM

  1. Pingback: DotNetShoutout
  2. Hey great post but I think it would be helpful to post code examples or give examples of where it would be beneficial to use each pattern

  3. Thanks Craig. Even I thought the same. But then decided against it to try explain them in a single para (as this is what I was looking for all this time). Code for these patterns are already there (I have linked few of them above), but I should be able to put few ones from my side soon.

  4. If you could add code snippets that would help. If it is not possible on this site then please email me.
    The information was very helpful.

  5. I am new to these patterns and still trying to sort out when to use what and where. For example, can MVVC be used for WinForms, WPF, or Silverlight?

  6. Thank you for this cool articles – samples would be really cool, a few of C#/Java pseudo-code would do it!


  7. great explanation! thanks. It would be wonderful to see code snippets for these. If not possible to pos them, please let me know the sites I can refer for it.

  8. Your diagrams for MVC don’t make any sense in this context.

    Models cannot raise events in Web MVC because there is no view to recieve the event until its time to render the page. Therefore the diagram must be of Classic MVC.

    However the text is clearly talking about the loosely coupled Web MVC design, a design that simply wouldn’t work for a rich client UI where you need to handle events from specific controls on the view.

    I think it is a real shame that the creators of the web pattern choose the name MVC. The Classic MVC pattern from SmallTalk was all about tightly coupled view-controller pairs that shared common models. The Web MVC pattern is about as far from that as you can get.

  9. Allen I guess you are referring to Page Controller which is slight variation over classic MVC. Diagrams listed are from a classic standpoint and web specific details are discussed later.

  10. Nice article,

    As you are here gives difference between MVC and MVVM, I am looking for a solution in Web. Actually i have created an one WinApplication uses MVVM, now i would like to reuse viewmodel in Asp.Net MVC, so have you any about using it? in MVVM have to use System.Windows.Input.ICommand ,but in case of we can not, so have you idea about using same application logic in Web and Windows?


  11. Well and good. It is easy to understand the diffs between MVC/MVP and MVVM. But I would like to see more on differences between MVVM and PM (Fowler’s). There are lots of misunderstanding between them as folks are mixing these two.


  12. Thanks Niraj…indeed a good article to differentiate between MVC, MVP & MVVM.

    Couple of things we will love to have on this article…

    1) Some details information on PRISM (with code snippet).
    2) Code snippet for all the above described patterns.

  13. Nice post. You might like to know that at you will find some useful MVVM stuff fow Windows Forms:
    1) a databinding library with converters that can also bind an Action to a property change
    2) a command binding library that can bind an Action to any input event of any UI component

  14. Good article! although would like to add one thing. In MVP, view and presenter should communicate through an interface which is missing from diagram.

  15. Hi Niraj, great article! It’d also be helpful if you could provide examples of types of applications or situations you would use these patterns in. For ex., I’ve seen MVVM being used in Silverlight applications, and have seen both MVC and MVP being used in a hybrid of ASP.NET/SharePoint type applications. However, I’m not sure if I know exactly why certain types of applications warrant that particular pattern. It might help users/followers if they are able to determine which pattern is best for the type of application they are about to implement.

  16. Great article, one note/question – classic MVC is saying that all user interactions are handled by Controller directly – in your diagram it looks that View is passing it to Controller – which one you think is correct?

  17. Kaniartur – please look at the ASP.NET MVC section of my post. I won’t say that is classic MVC, but most of they web frameworks work that way.

  18. Great post, but in MVC I don’t think user interacts with the view. Instead user interacts with the controller, the view is what the user sees but its the controller that handles user requests.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s