Alex‘s space: MVP vs MVC

Model View Presenter vs Model View Controller
Intro
In my work I often deal with the situation when people use MVС/MVP patters without clear understanding the really difference between them. In this article I will try to explain my view on the issue.
It’simportant to understand that in n-tier systems MVP/C patterns areresponsible for the presentation layer only. It’s not about how youbuild data or services layers, it’s about separating the data (model)and the user interface(view), telling you how the user interfacecommunicates with data. Using these patterns gives your applicationindependence on changing presentation without depending on data andcontrolling logic.
Generally:
1.       Model means data & business logicmodel. It’s not always a DataSet, DataTable or such stuff. It’s kind ofcomponents or classes which can provide data and can receive the datato store it somewhere else. To simplify understanding of Model justthink about it as “Façade” class.
2.       Viewrepresents data for the user. Generally it’s just the UI, and notalways UI logic. For example in ASP.NET the page with controls is View. The View can receive data directly from Model, but View never updates Model.
3.       The Presenter/Controllercontains the logic to update Model regarding the user’s actions intothe View. View only notifies Controller about user’s actions.Controller extracts data from View and sends it to Model.
Themain point of the MVC/P pattern is to split Model from View/Controllerto make Model independent from them. So, Model cannot contain thereferences to the V/C.
What is the MVC (model-view-controller)?
1.       Controller initializes the events of View interface to interact with model and controller.
2.       The user interacts with View (UI).
3.       Controller handles user’s events (can be the “observer” pattern) and asks Model to update.
4.       Model raises events, informing subscribers (View) about changes.
5.       View (UI) (subscribes to model events) handles Model’s evens and shows new Model’s data.
6.       The User Interface waits for the further user actions.
Primary points are:
1.       View does notuse Controller to update Model. Controller handles the events from Viewto manage user’s interaction and data (via interaction with Model)
2.       Controllercan be combined with the View. It’s what the Visual Studio do for theWindows Forms by default. The primary point is logical separation ofModel from the View.
3.       The Controller do not contains the rendering logic.
The example below illustrates the “Active-MVC” pattern, also known as “the original MVC pattern”.

There is also the “Passive-MVC” pattern.
The differences are that:
-         Model knows nothing about Controller and View, it only used by them both.
-         Controller uses View asking it to render new data.
-         View uses Model to get the data only when Controller ask View about it (no subscription between View and Model).
-         Controller handle Model data changes.
-         Controller may contain the rendering logic for the View.

And now we are close to MVP pattern.
MVP is like an MVC, but View doesn’t use Model.
In the MVP View and Model are utterly separated from each other using the Presenter. Any interaction between View and Model take place in Presenter.
Presenter is like the Controller, but which:
1.       handles the user events from View (in MVC View handles this events);
2.       updates Model using updated data from View (MVC passive just informs View to get/set new data from Model and MVC active takes no role in it, because Model informs View);
3.       examines Model for changes (like the MVC passive);
4.       (the main difference from MVC) gets Model data and stores them into View;
5.       (the main difference from MVC active) notifies View about updates;
6.       (difference from MVC) renders View using the Presenter

So, MVP has following pros:
1.       Model is separated from View and we can change View independently from Model
2.       We using Model more effective, because all interactions are now in one place –in the Presenter(Controller)
3.       Wecan use one Presenter(Controller) for many Views without changing thePresenter(Controller) logic, it’s can be useful because View changesmore often than the Presenter(Controller)
4.       If we are storing View logic in the Presenter(Controller) we can test the logic independent of user interaction (Unit Testing)
But there are cons:
1.       Too many interactions between View and Presenter because rendering View data is in the Presenter;
Also you need to understand that if you render too much data for View you are tied up on the particular View. So if  View needs to be changed you need to update the Presenter either, For example, if you rendered html and need to render the pdf, there is a big possibility that View need to be changed too.