【
注意Presenter跟View之间的关系，从Presenter出发的箭头并没有直接连在View上，而是跟View的“接口”相连，这就说明一个很重要的一点就是Presenter并不是直接跟具体的View紧密联系在一起，Presenter只知道View的Interface。这样做的好处就是让Presenter可以独立于具体的View而实现所有的logic， 如果之后改变View，只要相应的Interface没有更改，Presenter不用做任何改动。
】
As we can see from this diagram:
(1) View contains the Presenter instance (view "knows" presenter)
- (2) Presenter is the only class knowing how to reach to model and retrieve the data needed for performing
- business logic
- (3) Presenter talks to the View through the view interface (abstracted representation of the View without UI
- specific attributes)
- (4) View doesn't know nothing about the Model
【
2006年7月份，两岁大的MVP就“退休”了，取而代之的是基于MVP的两个“变种”，一个叫Supervising Controller, 另外一个叫Passive View。
】
In July 2006, two year old Model View Presenter pattern has been retired and two variations from original MVP pattern came up:
- Supervising controller - where the view is handling UI operations on his own based upon the DTO sent by presenter
- Passive screen (View)
Passive view is a type of MVP design pattern based on a concept that the view of interface should be abstracted representation of the view, where view UI elements would be represented with .NET plain data types.
In that way, presenter is (on decoupled way) aware of view UI elements so he could set/get values directly from the view, without the need of any DTO being used by view as a way of viewer<->presenter communication. .
The biggest advantage of the passive view is that leaves the view with only a "few lines of code" making it so simple that it doesn't require testing different then taking a quick look on the view code. Presenter is now having absolute control on view behavior so testing the presenter is all we have to do to verify even that the view works ok. Another very important advantage is: it enables active work separation between the UX's and DEV's, because DEV can make the complete view page logic without having a page(view) at all. All he has to do is to code against agreed view interface (page approximation). All UX guy has to do is to implement view interface on the view (which is pretty trivial thing to be done) and after that he has all the freedom to work not caring what DEV does.
【
Passive View的最大好处在于可以把UI设计和UI逻辑处理完全分开来做，这样DEV完全可以不需要设计Page，只需要有一个View的Interface就可以完成所有的逻辑处理工作。
负责UI的人只需要操作aspx和aspx.cs（这里面几乎没有什么代码，因为相关的事件处理都是放在Presenter中，UI只需要调用Presenter的方法即可）, 而负责Business Logic的人员负责presenter和model。
】
From what I learned from UX people I met so far, they want to stay away of code behind as much as possible. With supervising controller MVP implementation the question of ownership of actual page/control code behind (aspx.cs/ascx.cs) is unclear and usually ends having both UX/DEV working on it. With passive view, UX owns aspx and aspx.cs and DEV owns presenter and model. Amen! :)
The disadvantage of empowering the presenter is that it can lead to very complex presenter classes with a lot of things to be tested where some of them ay not be related strictly to business logic.
Anyhow, IMHO passive view extreme testability provides much greater gain than it causes pain with having more complex presenters. When we add to that equation ability of effective team multitasking enabling
View interface
View interface in passive view flavor of MVP is usually having much more members defined (comparing with supervising controller) because each one of the interface members represents abstraction of a view UI element.
【Passive View里面的属性(property/field)会相对多一些, 因为它要实现定义在Interface里面的所有属性。】
There are no events in the view interface
There are no DTO (data transfer object)
Due to the fact that presenter is indirectly manipulating the view elements and that the view is "dumb", there is no need for using any DTO objects because there is no need for presenter to pass any kind of data to the view, because view doesn't do anything.
Presenter
Presenter initialization
All the business logic of controlling,presenting and updating model and interaction with view should be encapsulated in the presenter. In this example Presenter is getting pointer to the view interface and model services through the utilization of constructor type of dependency injection design pattern.
readonly IUserService _userService;
readonly IUserDetailsView _view;
3:
public UserDetailsPresenter(IUserDetailsView view)
new UserServiceStub())
6: {
7: }
8:
public UserDetailsPresenter(IUserDetailsView view, IUserService userService)
10: {
11: _view = view;
12: _userService = userService;
13: }