从来没想了解过MVP。
最近做一个项目的设计，发现View和Control变成了双向关联，怎么都理不清楚。 后来高人说这是“Passive-MVC”。
转一篇帖子，看看什么是MVP。原帖： http://ameleta.spaces.live.com/b ... 45A821420!163.entry
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.
Mil thanks to Michael Nemtsev for coop |
|
陕公网安备：61019002000258 |
隐私政策 |
网站地图