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’s
important to understand that in n-tier systems MVP/C patterns are
responsible for the presentation layer only. It’s not about how you
build data or services layers, it’s about separating the data (model)
and the user interface(view), telling you how the user interface
communicates with data. Using these patterns gives your application
independence on changing presentation without depending on data and
controlling logic.
Generally:
1. Model means data & business logic
model. It’s not always a DataSet, DataTable or such stuff. It’s kind of
components or classes which can provide data and can receive the data
to store it somewhere else. To simplify understanding of Model just
think about it as “Façade” class.
2. View
represents data for the user. Generally it’s just the UI, and not
always 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/Controller
contains the logic to update Model regarding the user’s actions into
the View. View only notifies Controller about user’s actions.
Controller extracts data from View and sends it to Model.
The
main point of the MVC/P pattern is to split Model from View/Controller
to make Model independent from them. So, Model cannot contain the
references 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 not
use Controller to update Model. Controller handles the events from View
to manage user’s interaction and data (via interaction with Model)
2. Controller
can be combined with the View. It’s what the Visual Studio do for the
Windows Forms by default. The primary point is logical separation of
Model 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. We
can use one Presenter(Controller) for many Views without changing the
Presenter(Controller) logic, it’s can be useful because View changes
more 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.
