模型-视图-呈现器(MVP)

网上有人问MVP设计模式,不是最有价值球员,是Web开发中的一种名词,有很多人介绍这种设计模式,但没有给出中文的说法,这里的P是一个中间人的角色,本人不才杜撰了一个名词:呈现器,MVP也就成了模型-视图-呈现器设计模式,下面是stackoverflow上某人对MVP的解释,虽然他说的是Web开发,但对于其他应用也有价值,故这里翻译如下:

原文:http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference
翻译:sam sha – ycoder.com

模型-视图-呈现器

在MVP中,呈现器包含视图的UI业务逻辑,所有视图的调用直接委托给呈现器,呈现器使用接口与视图对话,避免了与视图的直接耦合,这意味着可以模拟视图组件进行单元测试。MVP中有一个特点,它存在很多个双向派发,比如,当点击“保存”按钮,事件委托呈现器“OnSave”方法,当完成保存,呈现器将通过接口回调视图,这样这个视图可以显示保存已完成。

MVP倾向于一种非常自然的模式实现Web Forms呈现的分离,原因是视图总是被ASP.NET运行器最先创建,你可以找到更多关于两者的资料

两点主要变化

被动视图:视图可以不包含任何逻辑,呈现器作为视图和模型之间对话的中间人,避免了视图与模型的直接接触,模型派发事件,呈现器进行分派并更新视图,在被动视图端,没有直接的数据绑定,取而代之的是视图公开的属性设置方法,以供呈现器使用和设置,所有的状态被呈现器管理而不是视图。

赞成:最大的可测试面,清晰的视图与模型分离
反对:相比自己作数据绑定,增加了更多的工作(如所有设置属性)

监管控制器:呈现器控制用户行为,视图直接与模型数据绑定,这种情况下,呈现器的职责是将模型传递给视图,呈现器同样包含行为逻辑如点击按钮,导航等等
赞成:利用数据绑定介绍了代码量
反对:减少了可测试的方面(因为数据绑定),直接访问模型导致视图缺少封装

模型-视图-控制器

在MVC中,控制器负责任何请求包括程序加载时响应什么样的视图,这与MVP不同,MVP中请求处理从视图移到了呈现器。MVC中视图的任何处理都与控制器的调用相关联,web上的每个请求包括一次访问在另一端都有一个控制器响应,当这个控制器完成处理,它将返回正确的视图,这个流程贯穿于整个应用程序的生命周期:

视图请求

–>调用控制器
–>控制器逻辑
–>控制器返回视图

表现模型

另一种模式是表现模型模式,这种模式中没有呈现器,取代的是视图直接与表现模型绑定,这个表现模型是专门制定视图的模型,这意味着这个模型可以公开属性,这是域模型无法做到的,因为这违背了关系分离的原则,在这种情况下,表现模型需要与域模型绑定,这样就可以订阅域模型上的事件,然后视图从表现模型上订阅事件,适时的更新。表现模型可以公开命令供视图调用,这种方式的优势是当PM完成视图行为的封装后,你可以基本上不需要编写隐藏的代码,这种模式为WPF程序提供了强有力的选择,它也被称为MVVM设计模式Model-View-ViewModel
MSDN中有一篇关于表现模型的文章,其中WPF混合应用向导中有一章节介绍表现分离模式


× 八 = 56