ASP.NET MVC 4框架揭秘：MVP（1）[1]

MVP（）

MVP是一种广泛使用的UI架构模式适用于基于事件驱动的应用框架比如ASPNET Web Forms和Windows Forms应用MVP中的M和V分别对应于MVC的Model和View而P（Presenter）则自然代替了MVC中的Controller但是MVP并非仅仅体现在从Controller到Presenter的转换更多地体现在ModelView和Presenter之间的交互上

MVC模式中元素之间混乱的交互主要体现在允许View和Model绕开Controller进行单独交流这在MVP模式中得到了彻底解决如图所示能够与Model直接进行交互的仅限于PresenterView只能通过Presenter间接地调用ModelModel的独立性在这里得到了真正的体现它不仅仅与可视化元素的呈现（View）无关与UI处理逻辑（Presenter）也无关使用MVP的应用是用户驱动的而非Model驱动的所以Model不需要主动通知View以提醒状态发生了改变

图 ModelViewPresenter之间的交互

MVP不仅仅避免了View和Model之间的耦合更进一步地降低了Presenter对View的依赖如图所示Presenter依赖的是一个抽象化的View即View实现的接口IView这带来的最直接的好处就是使定义在Presenter中的UI处理逻辑变得易于测试由于Presenter对View的依赖行为定义在接口IView中我们只需要Mock一个实现了该接口的View就能对Presenter进行测试

构成MVP三要素之间的交互体现在两个方面即View/Presenter和Presenter/ModelPresenter和Model之间的交互很清晰仅仅体现在Presenter对Model的单向调用而View和Presenter之间该采用怎样的交互方式是整个MVP的核心MVP针对关注点分离的初衷能否体现在具体的应用中很大程度上取决于两者之间的交互方式是否正确按照View和Presenter之间的交互方式以及View本身的职责范围Martin Folwer将MVP可分为PV（Passive View）和SC（Supervising Controller）两种模式

PV与SC

解决View难以测试的最好的办法就是让它无需测试如果View不需要测试其先决条件就是让它尽可能不涉及到UI处理逻辑这就是PV模式目的所在顾名思义PV（Passive View）是一个被动的View包含其中的针对UI元素（比如控件）的操作不是由View自身主动来控制而被动地交给Presenter来操控

如果我们纯粹地采用PV模式来设计View意味着我们需要将View中的UI元素通过属性的形式暴露出来具体来说当我们在为View定义接口的时候需要定义基于UI元素的属性使Presenter可以对View进行细粒度操作但这并不意味着我们直接将View上的控件暴露出来举个简单的例子假设我们开发的HR系统中具有如图所示的一个Web页面我们通过它可以获取某个部门的员工列表

图 员工查询页面

现在通过ASPNET Web Forms应用来设计这个页面我们来讨论一下如果采用PV模式View的接口该如何定义对于Presenter来说View供它操作的控件有两个一个是包含所有部门列表的DropDownList另一个则是显示员工列表的GridView在页面加载的时候Presenter将部门列表绑定在DropDownList上与此同时包含所有员工的列表被绑定到GridView当用户选择某个部门并点击查询按钮后View将包含筛选部门在内的查询请求转发给Presenter后者筛选出相应的员工列表之后将其绑定到GridView

如果我们为该View定义一个接口IEmployeeSearchView我们不能按照所示的代码将上述这两个控件直接以属性的形式暴露出来针对具体控件类型的数据绑定属于View的内部细节（比如说针对部门列表的显示我们可以选择DropDownList也可以选择ListBox）不能体现在表示用于抽象View的接口中另外理想情况下定义在Presenter中的UI处理逻辑应该是与具体的技术平台无关的如果在接口中涉及控件类型这无疑将Presenter也与具体的技术平台绑定在了一起

public interface IEmployeeSearchView

{

DropDownList Departments { get;}

GridView Employees { get; }

}

[] []