What are MVP and MVC and what is the difference?

Answer 1

Here are illustrations which represent communication flow

Answer 2

There are many answers to the question, but I felt there is a need for some really simple answer clearly comparing the two. Here's the discussion I made up when a user searches for a movie name in an MVP and MVC app:

User: Click click …

View: Who’s that? [MVP|MVC]

User: I just clicked on the search button …

View: Ok, hold on a sec … . [MVP|MVC]

( View calling the Presenter|Controller … ) [MVP|MVC]

View: Hey Presenter|Controller, a User has just clicked on the search button, what shall I do? [MVP|MVC]

Presenter|Controller: Hey View, is there any search term on that page? [MVP|MVC]

View: Yes,… here it is … “piano” [MVP|MVC]

Presenter: Thanks View,… meanwhile I’m looking up the search term on the Model, please show him/her a progress bar [MVP|MVC]

( Presenter|Controller is calling the Model … ) [MVP|MVC]

Presenter|Controller: Hey Model, Do you have any match for this search term?: “piano” [MVP|MVC]

Model: Hey Presenter|Controller, let me check … [MVP|MVC]

( Model is making a query to the movie database … ) [MVP|MVC]

( After a while ... )

-------------- This is where MVP and MVC start to diverge ---------------

Model: I found a list for you, Presenter, here it is in JSON “[{"name":"Piano Teacher","year":2001},{"name":"Piano","year":1993}]” [MVP]

Model: There is some result available, Controller. I have created a field variable in my instance and filled it with the result. It's name is "searchResultsList" [MVC]

(Presenter|Controller thanks Model and gets back to the View) [MVP|MVC]

Presenter: Thanks for waiting View, I found a list of matching results for you and arranged them in a presentable format: ["Piano Teacher 2001","Piano 1993"]. Please show it to the user in a vertical list. Also please hide the progress bar now [MVP]

Controller: Thanks for waiting View, I have asked Model about your search query. It says it has found a list of matching results and stored them in a variable named "searchResultsList" inside its instance. You can get it from there. Also please hide the progress bar now [MVC]

View: Thank you very much Presenter [MVP]

View: Thank you "Controller" [MVC] (Now the View is questioning itself: How should I present the results I get from the Model to the user? Should the production year of the movie come first or last...? Should it be in a vertical or horizontal list? ...)

In case you're interested, I have been writing a series of articles dealing with app architectural patterns (MVC, MVP, MVVP, clean architecture, ...) accompanied by a Github repo here. Even though the sample is written for android, the underlying principles can be applied to any medium.

Answer 3

The simplest answer is how the view interacts with the model. In MVP the view is updated by the presenter, which acts as as intermediary between the view and the model. The presenter takes the input from the view, which retrieves the data from the model and then performs any business logic required and then updates the view. In MVC the model updates the view directly rather than going back through the controller.

Answer 4

• MVP = Model-View-Presenter

• MVC = Model-View-Controller

  1. Both presentation patterns. They separate the dependencies between a Model (think Domain objects), your screen/web page (the View), and how your UI is supposed to behave (Presenter/Controller)
  2. They are fairly similar in concept, folks initialize the Presenter/Controller differently depending on taste.
  3. A great article on the differences is here. Most notable is that MVC pattern has the Model updating the View.

Answer 5

You forgot about Action-Domain-Responder (ADR).

As explained in some graphics above, there's a direct relation/link between the Model and the View in MVC. An action is performed on the Controller, which will execute an action on the Model. That action in the Model, will trigger a reaction in the View. The View, is always updated when the Model's state changes.

Some people keep forgetting, that MVC was created in the late 70", and that the Web was only created in late 80"/early 90". MVC wasn't originally created for the Web, but for Desktop applications instead, where the Controller, Model and View would co-exist together.

Because we use web frameworks (eg:. Laravel) that still use the same naming conventions (model-view-controller), we tend to think that it must be MVC, but it's actually something else.

Instead, have a look at Action-Domain-Responder. In ADR, the Controller gets an Action, which will perform an operation in the Model/Domain. So far, the same. The difference is, it then collects that operation's response/data, and pass it to a Responder (eg:. view()) for rendering. When a new action is requested on the same component, the Controller is called again, and the cycle repeats itself. In ADR, there's no connection between the Model/Domain and the View (Reponser's response).

Note: Wikipedia states that "Each ADR action, however, is represented by separate classes or closures.". This is not necessarily true. Several Actions can be in the same Controller, and the pattern is still the same.

mvc adr model-view-controller action-domain-responder

Answer 6

MVP

MVP stands for Model - View- Presenter. This came to a picture in early 2007 where Microsoft introduced Smart Client windows applications.

A presenter is acting as a supervisory role in MVP which binding View events and business logic from models.

View event binding will be implemented in the Presenter from a view interface.

The view is the initiator for user inputs and then delegates the events to the Presenter and the presenter handles event bindings and gets data from models.

Pros: The view is having only UI not any logics High level of testability

Cons: Bit complex and more work when implementing event bindings

MVC

MVC stands for Model-View-Controller. Controller is responsible for creating models and rendering views with binding models.

Controller is the initiator and it decides which view to render.

Pros: Emphasis on Single Responsibility Principle High level of testability

Cons: Sometimes too much workload for Controllers, if try to render multiple views in same controller.