当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:

这些模式解决了什么问题?它们有什么相似之处?它们有何不同?


当前回答

MVP不一定是视图负责的场景(例如,参见Taligent的MVP)。我觉得很不幸的是,人们仍在宣扬这是一种模式(主管视图),而不是一种反模式,因为它与“这只是一种观点”(实用主义程序员)相矛盾。“这只是一个视图”表示,向用户显示的最终视图是应用程序的次要关注点。微软的MVP模式使视图的重用变得更加困难,并方便地为微软的设计师提供了避免不良做法的借口。

坦率地说,我认为MVC的底层关注点对于任何MVP实现都是正确的,它们之间的差异几乎完全是语义上的。只要您遵循视图(显示数据)、控制器(初始化和控制用户交互)和模型(底层数据和/或服务)之间的关注点分离,就可以实现MVC的好处。如果您正在实现这些好处,那么谁会真正关心您的模式是MVC、MVP还是Supervisory Controller?唯一真正的模式仍然是MVC,其余的只是不同的风格。

考虑一下这篇激动人心的文章,它全面列出了许多不同的实现。你可能会注意到,他们基本上都在做相同的事情,但略有不同。

我个人认为MVP是最近才被重新引入的一个吸引人的术语,目的是为了减少语义偏执者之间的争论,他们争论某些东西是否真正是MVC,或者是为了证明微软的快速应用程序开发工具的合理性。在我的书中,这两个原因都不能证明它是一种独立的设计模式。

其他回答

表示器

在MVP中,演示者包含视图的UI业务逻辑。视图中的所有调用都直接委派给演示者。演示者也直接与视图分离,并通过接口与视图对话。这是为了允许在单元测试中模拟视图。MVP的一个共同特点是必须有很多双向调度。例如,当有人单击“保存”按钮时,事件处理程序将委托给演示者的“OnSave”方法。保存完成后,演示者将通过其界面调用视图,以便视图显示保存已完成。

MVP往往是在WebForms中实现分离表示的一种非常自然的模式。原因是视图总是首先由ASP.NET运行时创建。您可以了解更多关于这两种变体的信息。

两种主要变化

被动视图:视图尽可能地哑,几乎包含零逻辑。演示者是与视图和模型对话的中间人。视图和模型彼此完全屏蔽。模型可能会引发事件,但演示者会订阅这些事件以更新视图。在被动视图中,没有直接的数据绑定,相反,视图公开了演示者用于设置数据的setter财产。所有状态都在演示者中管理,而不是在视图中管理。

Pro:最大可测试表面;视图和模型的清晰分离缺点:更多的工作(例如所有setter财产),因为您正在自己进行所有数据绑定。

监督控制器:演示者处理用户手势。视图通过数据绑定直接绑定到模型。在这种情况下,演示者的工作是将模型传递给视图,以便它可以绑定到它。演示者还将包含诸如按下按钮、导航等手势的逻辑。

优点:通过利用数据绑定,减少了代码量。缺点:有一个不太可测试的表面(因为数据绑定),并且视图中的封装更少,因为它直接与模型对话。

模型视图控制器

在MVC中,控制器负责确定响应于任何操作(包括应用程序加载时)显示哪个视图。这与MVP不同,MVP将动作通过视图传递到演示者。在MVC中,视图中的每个动作都与对Controller的调用以及动作相关。在网络中,每个动作都涉及到对URL的调用,URL的另一端有一个控制器进行响应。控制器完成处理后,将返回正确的视图。该序列在应用程序的整个生命周期中以这种方式继续:

    Action in the View
        -> Call to Controller
        -> Controller Logic
        -> Controller returns the View.

MVC的另一个重要区别是视图不直接绑定到模型。该视图只是呈现,完全无状态。在MVC的实现中,视图通常在代码后面没有任何逻辑。这与MVP相反,MVP是绝对必要的,因为如果视图不委托给演示者,它将永远不会被调用。

演示模型

另一种模式是演示模型模式。在此模式中,没有演示者。相反,视图直接绑定到演示模型。演示模型是专门为视图设计的模型。这意味着该模型可以公开人们永远不会放在域模型上的财产,因为这将违反关注分离。在这种情况下,表示模型绑定到域模型,并可以订阅来自该模型的事件。然后,视图订阅来自演示模型的事件,并相应地更新自己。表示模型可以公开视图用于调用操作的命令。这种方法的优点是,当PM完全封装了视图的所有行为时,您基本上可以完全删除代码。这种模式非常适合在WPF应用程序中使用,也称为模型视图视图模型。

MSDN上有一篇关于演示模型的文章,WPF(前Prism)的复合应用指南中有一节关于分离的演示模式

在MVP中,视图从演示者中提取数据,演示者从模型中提取数据并准备/规范化数据,而在MVC中,控制器通过在视图中推送从模型中获取数据并进行设置。

在MVP中,您可以使用一个视图来处理多种类型的演示者,也可以使用单个演示者来处理不同的多个视图。

MVP通常使用某种绑定框架,例如Microsoft WPF绑定框架或HTML5和Java的各种绑定框架。

在这些框架中,UI/HTML5/XAML知道每个UI元素显示的演示者的属性,因此当您将视图绑定到演示者时,视图会查找财产,并知道如何从中绘制数据,以及当用户在UI中更改值时如何设置这些属性。

因此,例如,如果模型是一辆汽车,那么演示者是某种汽车演示者,向视图公开汽车的财产(年份、制造商、座位等)。视图知道名为“car maker”的文本字段需要显示演示者maker属性。

然后,您可以将许多不同类型的演示者绑定到视图中,所有演示者都必须具有Maker属性-它可以是飞机、火车或其他任何类型的视图,视图都不在乎。视图从演示者(无论是哪一个)获取数据,只要它实现了一个商定的接口。

这个绑定框架,如果你去掉它,它实际上就是控制器:-)

因此,您可以将MVP视为MVC的演变。

MVC很好,但问题是它的控制器通常是每个视图。控制器A知道如何设置视图A的字段。如果现在,您希望视图A显示模型B的数据,您需要控制器A了解模型B,或者需要控制器A接收带有接口的对象,这就像MVP一样,只是没有绑定,或者您需要重写控制器B中的UI设置代码。

结论:MVP和MVC都是UI模式的解耦,但MVP通常使用一个绑定框架,该框架的底层是MVC。THUS MVP的体系结构级别高于MVC,并且是MVC之上的包装模式。

我已经使用了MVP和MVC,尽管我们作为开发人员倾向于关注这两种模式的技术差异,但IMHO中MVP的要点与易于采用性比其他任何东西都更相关。

如果我所在的团队已经具备良好的web表单开发风格背景,那么引入MVP比引入MVC要容易得多。我认为MVP在这种情况下是一场快速的胜利。

我的经验告诉我,将团队从web表单转移到MVP,然后从MVP转移到MVC相对容易;从web表单迁移到MVC更加困难。

我在这里留下一个链接,指向我的一个朋友发表的关于MVP和MVC的一系列文章。

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

这个问题有很多答案,但我觉得需要一些非常简单的答案来清楚地比较两者。以下是我在用户在MVP和MVC应用程序中搜索电影名称时所做的讨论:

用户:单击…

观点:那是谁?[MVP|MVC]

用户:我刚刚点击了搜索按钮…

视图:好的,等一下。[MVP|MVC]

(视图调用演示者|控制器…)[MMVP|MVC]

视图:嗨,演示者|控制器,用户刚刚单击了搜索按钮,我该怎么办?[MVP|MVC]

演示者|控制器:嘿,View,那个页面上有搜索词吗?[MVP|MVC]

视图:是的,…这里是…“钢琴”[MMVP|MVC]

演示者|控制器:谢谢查看,……同时我正在查找模型上的搜索项,请向他/她显示进度条[MVP|MVC]

(演示者|控制器正在调用模型…)[MMVP|MVC]

演示者|控制器:嘿,模特儿,你有匹配这个搜索词的吗?:“钢琴”[MVP|MVC]

模型:嘿,演示者|控制器,让我检查一下…〔MVP|MVC〕

(模型正在对电影数据库进行查询…)[MVP|MVC]

(过了一会儿…)

--------------这就是MVP和MVC开始分化的地方---------------

模型:我为您找到了一个列表,演示者,这里是JSON格式的“[{“name”:“Piano Teacher”,“year”:2001},{“name:”Piano”,“year”:1993}]”[MVP]

模型:有一些结果可用,控制器。我在实例中创建了一个字段变量,并用结果填充它。它的名称是“searchResultsList”[MVC]

(演示者|控制器感谢模型并返回视图)[MMVP|MVC]

演示者:感谢等待View,我为您找到了一个匹配结果列表,并以可呈现的格式排列:[“Piano Teacher 2001”,“Piano 1993”]。请在垂直列表中向用户显示。也请现在隐藏进度条[MMVP]

控制器:感谢等待View,我已经向Model询问了您的搜索查询。它说它找到了一个匹配结果的列表,并将它们存储在其实例中名为“searchResultsList”的变量中。你可以从那里得到它。也请立即隐藏进度条[MVC]

观点:非常感谢演示者MVP

视图:谢谢“控制器”[MVC](现在,视图正在质疑自己:我应该如何向用户展示我从模型中获得的结果?电影的制作年份应该是第一年还是最后一年……?它应该在垂直列表还是水平列表中?…)

如果你感兴趣的话,我一直在写一系列关于应用程序架构模式(MVC、MVP、MVVP、干净架构……)的文章,并在这里附上Github repo。尽管该示例是为android编写的,但其基本原理可以应用于任何介质。

MVP=模型视图演示者MVC=模型视图控制器两种演示模式。它们将模型(考虑域对象)、屏幕/网页(视图)和用户界面(演示者/控制器)之间的依赖关系分开它们在概念上相当相似,人们根据口味对演示者/控制器进行不同的初始化。这里有一篇关于差异的精彩文章。最值得注意的是MVC模式具有更新视图的模型。