当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当超越RAD(拖放和配置)构建用户界面的方式时,许多工具都鼓励您使用三种设计模式,即模型视图控制器、模型视图演示器和模型视图视图模型。我的问题有三个部分:
这些模式解决了什么问题?它们有什么相似之处?它们有何不同?
当前回答
其他回答
简而言之,
在MVC中,View有UI部分,它调用控制器,控制器反过来调用模型&模型,然后将事件返回视图。在MVP中,视图包含UI,并调用演示者作为实现部分。演示者直接调用视图以更新UI部分。包含业务逻辑的模型由演示者调用,与视图没有任何交互。因此,演示者完成了大部分工作:)
这是对这些设计模式的许多变体的过度简化,但这是我喜欢思考两者之间差异的方式。
MVC
MVP
这两个框架都旨在分离关注点-例如,与数据源(模型)的交互、应用程序逻辑(或将这些数据转换为有用信息)(控制器/演示者)和显示代码(视图)。在某些情况下,模型还可以用于将数据源转换为更高级别的抽象。MVC Storefront项目就是一个很好的例子。
这里讨论了MVC与MVP之间的区别。
所做的区别在于,在MVC应用程序中,视图和控制器传统上与模型交互,而不是彼此交互。
MVP设计让演示者访问模型并与视图交互。
尽管如此,根据这些定义,ASP.NET MVC是MVP框架,因为控制器访问模型以填充视图,这意味着没有逻辑(只显示控制器提供的变量)。
要了解ASP.NET MVC与MVP的区别,请查看Scott Hanselman的MIX演示。
不久前,我在博客中引用了托德·斯奈德(Todd Snyder)关于两者区别的精彩文章:
以下是模式:MVP模式视图与模型的耦合更加松散。演示者是负责将模型绑定到视图。更容易进行单元测试,因为与视图的交互是通过的接口通常视图到演示者的映射是一对一。复杂视图可能具有多主持人。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编写的,但其基本原理可以应用于任何介质。