design-patterns model-view-controller mvp terminology user-interface

What are MVP and MVC and what is the difference?


When looking beyond the RAD (drag-drop and configure) way of building user interfaces that many tools encourage you are likely to come across three design patterns called Model-View-Controller, Model-View-Presenter and Model-View-ViewModel. My question has three parts to it:

  1. What issues do these patterns address?
  2. How are they similar?
  3. How are they different?


  • 6

    – givanse

    Dec 11, 2016 at 16:51

  • 3

    IDK, but supposedly for the original MVC, it was meant to be used in the small. Each button, label, etc, had its’ own view and controller object, or at least that is what Uncle Bob claims. I think he was talking about Smalltalk. Look up his talks on YouTube, they are fascinating.

    Sep 3, 2017 at 1:19

  • 1

    MVP adds an extra layer of indirection by splitting the View-Controller into a View and a Presenter…

    – the_prole

    Jan 26, 2018 at 2:33

  • 4

    The main difference is that in MVC the Controller does not pass any data from the Model to the View. It just notifies the View to get the data from the Model itself. However, in MVP, there is no connection between the View and Model. The Presenter itself gets any data needed from the Model and passes it to the View to show. More to this together with an android sample in all architecture patterns is here:

    – Ali Nem

    Mar 19, 2018 at 11:49

  • 1

    They are called architectural patterns not design patterns. If you want to know the difference, check this

    Jun 2, 2019 at 22:17



In MVP, the Presenter contains the UI business logic for the View. All invocations from the View delegate directly to the Presenter. The Presenter is also decoupled directly from the View and talks to it through an interface. This is to allow mocking of the View in a unit test. One common attribute of MVP is that there has to be a lot of two-way dispatching. For example, when someone clicks the “Save” button, the event handler delegates to the Presenter’s “OnSave” method. Once the save is completed, the Presenter will then call back the View through its interface so that the View can display that the save has completed.

MVP tends to be a very natural pattern for achieving separated presentation in WebForms. The reason is that the View is always created first by the ASP.NET runtime. You can find out more about both variants.

Two primary variations

Passive View: The View is as dumb as possible and contains almost zero logic. A Presenter is a middle man that talks to the View and the Model. The View and Model are completely shielded from one another. The Model may raise events, but the Presenter subscribes to them for updating the View. In Passive View there is no direct data binding, instead, the View exposes setter properties that the Presenter uses to set the data. All state is managed in the Presenter and not the View.

  • Pro: maximum testability surface; clean separation of the View and Model
  • Con: more work (for example all the setter properties) as you are doing all the data binding yourself.

Supervising Controller: The Presenter handles user gestures. The View binds to the Model directly through data binding. In this case, it’s the Presenter’s job to pass off the Model to the View so that it can bind to it. The Presenter will also contain logic for gestures like pressing a button, navigation, etc.

  • Pro: by leveraging data binding the amount of code is reduced.
  • Con: there’s a less testable surface (because of data binding), and there’s less encapsulation in the View since it talks directly to the Model.


In the MVC, the Controller is responsible for determining which View to display in response to any action including when the application loads. This differs from MVP where actions route through the View to the Presenter. In MVC, every action in the View correlates with a call to a Controller along with an action. In the web, each action involves a call to a URL on the other side of which there is a Controller who responds. Once that Controller has completed its processing, it will return the correct View. The sequence continues in that manner throughout the life of the application:

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

One other big difference about MVC is that the View does not directly bind to the Model. The view simply renders and is completely stateless. In implementations of MVC, the View usually will not have any logic in the code behind. This is contrary to MVP where it is absolutely necessary because, if the View does not delegate to the Presenter, it will never get called.

Presentation Model

One other pattern to look at is the Presentation Model pattern. In this pattern, there is no Presenter. Instead, the View binds directly to a Presentation Model. The Presentation Model is a Model crafted specifically for the View. This means this Model can expose properties that one would never put on a domain model as it would be a violation of separation-of-concerns. In this case, the Presentation Model binds to the domain model and may subscribe to events coming from that Model. The View then subscribes to events coming from the Presentation Model and updates itself accordingly. The Presentation Model can expose commands which the view uses for invoking actions. The advantage of this approach is that you can essentially remove the code-behind altogether as the PM completely encapsulates all of the behavior for the view. This pattern is a very strong candidate for use in WPF applications and is also called Model-View-ViewModel.

There is a MSDN article about the Presentation Model and a section in the Composite Application Guidance for WPF (former Prism) about Separated Presentation Patterns


  • 38

    Can you please clarify this phrase? This differs from MVP where actions route through the View to the Presenter. In MVC, every action in the View correlates with a call to a Controller along with an action. To me, it sounds like the same thing, but I’m sure you’re describing something different.

    Oct 19, 2016 at 13:24

  • 17

    @Panzercrisis I’m not sure if this is what the author meant, but this is what I think they were trying to say. Like this answer – mentions, in MVC, controller methods are based on behaviors — in other words, you can map multiple views (but same behavior) to a single controller. In MVP, the presenter is coupled closer to the view, and usually results in a mapping that is closer to one-to-one, i.e. a view action maps to its corresponding presenter’s method. You typically wouldn’t map another view’s actions to another presenter’s (from another view) method.

    Oct 28, 2016 at 17:50

  • 4

    Note that MVC is often used by web-frameworks like Laravel, where the received URL requests (maybe made by users) are handled by the Controller and the HTML generated by the View is sent to the client — So, the View is a part of the backend and the user can never access it directly, and if you experience anywhere the opposite then consider that as an MVC-extension (or even violation). @Panzercrisis, This differs from MVP (like that used in Android OS) where actions route through the View to the Presenter and user have direct access to the View.

    Sep 29, 2019 at 11:50

  • 4

    What the author describes when speaking about MVC isn’t the original Smalltalk MVC (whose flow is triangular) but the “Web MVC” where the controller renders a view using a model and returns it to the user. I believe this is worth noting because this creates a lot of confusion.

    – raiks

    Jul 15, 2020 at 8:47


This is an oversimplification of the many variants of these design patterns, but this is how I like to think about the differences between the two.




enter image description here


  • 11

    This is a great depiction of the schematic, showing the abstraction and complete isolation of any GUI related (view stuff) from the API of the presenter. One minor point: A master presenter could be used where there is only one presenter, rather than one per view, but your diagram is the cleanest. IMO, the biggest difference between MVC/MVP is that MVP tries to keep the view totally void of anything other than display of the current ‘view state’ (view data), while also disallowing the view any knowledge of Model objects. Thus the interfaces, needing to be there, to inject that state.

    – user2080225

    Oct 15, 2013 at 3:30

  • 4

    Good picture. I use MVP quite a lot, so I’d like to make one point. In my experience, the Presenters need to talk to one another quite often. Same is true for the Models (or Business objects). Because of these additional “blue lines” of communication that would be in your MVP pic, the Presenter-Model relationships can become quite entangled. Therefore, I tend to keep a one-to-one Presenter-Model relationship vs. a one-to-many. Yes, it requires some additional delegate methods on the Model, but it reduces many headaches if the API of the Model changes or needs refactoring.

    Feb 28, 2014 at 14:45

  • 3

    The MVC example is wrong; there’s a strict 1:1 relationship between views and controllers. By definition, a controller interprets human gesture input to produce events for the model and view alike for a single control. More simply, MVC was intended for use with individual widgets only. One widget, one view, one control.

    Apr 5, 2014 at 15:34

  • 3

    @SamuelA.FalvoII not always, there is a 1:Many between controllers and views in ASP.NET MVC:…

    Jan 7, 2016 at 17:57

  • 5

    @StuperUser — Not sure what I was thinking when I wrote that. You’re right, of course, and looking back on what I wrote, I have to wonder if I had some other context in mind which I failed to articulate. Thanks for the correction.

    Jan 11, 2016 at 23:40


I blogged about this a while back, quoting on Todd Snyder’s excellent post on the difference between the two:

Here are the key differences between
the patterns:

MVP Pattern

  • View is more loosely coupled to the model. The presenter is
    responsible for binding the model to
    the view.
  • Easier to unit test because interaction with the view is through
    an interface
  • Usually view to presenter map one to one. Complex views may have
    multi presenters.

MVC Pattern

  • Controller are based on behaviors and can be shared across
  • Can be responsible for determining which view to display

It is the best explanation on the web I could find.


  • 18

    I don’t understand how in the view can be coupled more or less closely to the model when in both cases the entire point is to completely decouple them. I’m not implying you said something wrong–just confused as to what you mean.

    – Bill K

    Oct 5, 2011 at 0:25

  • 20

    @pst: with MVP it’s really 1 View = 1 Presenter. With MVC, the Controller can govern multiple views. That’s it, really. With the “tabs” model imagine each tab having its own Presenter as opposed to having one Controller for all tabs.

    Jun 29, 2012 at 9:46

  • 4

    Originally there are two types of controllers: the one which you said to be shared across multiple views, and those who are views specific, mainly purposed for adapting the interface of the shared controller.

    – Acsor

    Nov 11, 2013 at 14:12

  • 1

    @JonLimjap What does it mean by one view anyway? In the context of iOS programming, is it one-screenful? Does this make iOS’s controller more like MVP than MVC? (On the other hand you can also have multiple iOS controllers per screen)

    – huggie

    Mar 19, 2014 at 7:55

  • 2

    Well Todd’s diagramatic illustration of MVC completely contradicts the idea of decoupling the View and Model. If you look at the diagram, it says Model updates View (arrow from Model to View). In which universe is a system, where the Model directly interacts with the View, a decoupled one???

    – Ash

    Jun 4, 2017 at 2:01