当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当前回答
我简短的观点是:MVP适用于大范围,MVC适用于小范围。有了MVC,我有时会觉得V和C可能被看作是一个不可分割的组件的两面,而不是直接绑定到M,当向下扩展到较短的规模时,如UI控件和基本控件时,必然会出现这种情况。在这种粒度级别上,MVP意义不大。相反,当一个人走向更大的规模时,适当的界面变得更重要,同样,明确的职责分配也同样重要,MVP就来了。
另一方面,当平台特性有助于组件之间的某种关系时,例如在web上,MVC的实现似乎比MVP更容易。
其他回答
MVC(模型视图控制器)
在MVC中,控制器是负责人!控制器根据一些事件/请求触发或访问,然后管理视图。
MVC中的视图实际上是无状态的,控制器负责选择要显示的视图。
例如:当用户单击“Show MyProfile”(显示我的配置文件)按钮时,将触发控制器。它与模型通信以获得适当的数据。然后,它会显示一个类似于配置文件页面的新视图。控制器可以从模型中获取数据并将其直接馈送到视图(如上图所示),或者让视图从模型本身获取数据。
MVP(模型视图演示者)
在MVP中,视图是负责人!每个视图都会调用其演示者或演示者收听的某些事件。
MVP中的视图不实现任何逻辑,演示者负责实现所有逻辑,并使用某种接口与视图进行通信。
例如:当用户单击“保存”按钮时,视图中的事件处理程序将委派给演示者的“OnSave”方法。演示者将执行所需的逻辑,并与模型进行任何所需的通信,然后通过其界面调用视图,以便视图显示保存已完成。
MVC与MVP
MVC并没有让视图负责,视图充当控制器可以管理和指导的从属对象。在MVC中,视图是无状态的,而MVP中的视图是有状态的,可以随时间变化。在MVP中,视图没有逻辑,我们应该尽可能让它们保持沉默。另一方面,MVC中的视图可能有某种逻辑。在MVP中,演示者与视图分离,并通过接口与视图对话。这允许在单元测试中模拟视图。在MVP中,视图与模型完全隔离。然而,在MVC中,视图可以与模型通信,以使其与最新的最新数据。
我认为Erwin Vanderwalk的这张图片(以及附带的文章)是对MVC、MVP和MVVM及其相似性和差异的最好解释。这篇文章没有出现在搜索引擎的“MVC、MVP和MVVM”查询结果中,因为文章的标题没有包含“MVC”和“MVP”字样;但我认为这是最好的解释。
(这篇文章也符合鲍勃·马丁大叔在他的一次演讲中所说的:MVC最初是为小型UI组件而设计的,而不是为系统的架构而设计的)
MVP:观点是主导的。
在大多数情况下,视图会创建其演示者。演示者将与模型交互并通过界面操纵视图。视图有时会与演示者交互,通常是通过某种界面。这归结于实施;您希望视图调用演示者上的方法,还是希望视图具有演示者侦听的事件?归结起来就是:视图了解演示者。视图将委派给演示者。
MVC:控制器负责。
控制器是根据某些事件/请求创建或访问的。然后,控制器创建适当的视图并与模型交互以进一步配置视图。它归结为:控制器创建和管理视图;视图从属于控制器。视图不知道控制器。
MVP=模型视图演示者MVC=模型视图控制器两种演示模式。它们将模型(考虑域对象)、屏幕/网页(视图)和用户界面(演示者/控制器)之间的依赖关系分开它们在概念上相当相似,人们根据口味对演示者/控制器进行不同的初始化。这里有一篇关于差异的精彩文章。最值得注意的是MVC模式具有更新视图的模型。
这个问题有很多答案,但我觉得需要一些非常简单的答案来清楚地比较两者。以下是我在用户在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编写的,但其基本原理可以应用于任何介质。