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

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


当前回答

MVC(模型视图控制器)

输入首先指向控制器,而不是视图。该输入可能来自与页面交互的用户,但也可能来自简单地在浏览器中输入特定的url。在任何一种情况下,它都是一个控制器,与之接口以启动某些功能。控制器和视图之间存在多对一关系。这是因为单个控制器可以基于正在执行的操作选择要渲染的不同视图。注意从控制器到视图的单向箭头。这是因为视图对控制器没有任何了解或参考。控制器确实会传递回模型,因此视图和传递给它的预期模型之间存在知识,而不是提供服务的控制器。

MVP(模型视图演示者)

输入以视图开始,而不是演示者。视图和关联的演示者之间有一对一的映射。视图包含对演示者的引用。演示者也会对从视图触发的事件做出反应,从而了解与其关联的视图。演示者根据对模型执行的请求操作更新视图,但视图不支持模型。

更多参考信息

其他回答

以下是表示通信流程的图示



我简短的观点是:MVP适用于大范围,MVC适用于小范围。有了MVC,我有时会觉得V和C可能被看作是一个不可分割的组件的两面,而不是直接绑定到M,当向下扩展到较短的规模时,如UI控件和基本控件时,必然会出现这种情况。在这种粒度级别上,MVP意义不大。相反,当一个人走向更大的规模时,适当的界面变得更重要,同样,明确的职责分配也同样重要,MVP就来了。

另一方面,当平台特性有助于组件之间的某种关系时,例如在web上,MVC的实现似乎比MVP更容易。

这两个框架都旨在分离关注点-例如,与数据源(模型)的交互、应用程序逻辑(或将这些数据转换为有用信息)(控制器/演示者)和显示代码(视图)。在某些情况下,模型还可以用于将数据源转换为更高级别的抽象。MVC Storefront项目就是一个很好的例子。

这里讨论了MVC与MVP之间的区别。

所做的区别在于,在MVC应用程序中,视图和控制器传统上与模型交互,而不是彼此交互。

MVP设计让演示者访问模型并与视图交互。

尽管如此,根据这些定义,ASP.NET MVC是MVP框架,因为控制器访问模型以填充视图,这意味着没有逻辑(只显示控制器提供的变量)。

要了解ASP.NET MVC与MVP的区别,请查看Scott Hanselman的MIX演示。

MVP

MVP代表模型-视图-演示者。2007年初,微软推出了Smart Client windows应用程序。

演示者在MVP中充当监督角色,MVP绑定模型中的视图事件和业务逻辑。

视图事件绑定将从视图界面在Presenter中实现。

视图是用户输入的发起者,然后将事件委派给演示者,演示者处理事件绑定并从模型中获取数据。

赞成的意见:视图只有UI,没有任何逻辑高水平的可测试性

欺骗:实现事件绑定时有点复杂,工作量更大

MVC

MVC代表模型视图控制器。控制器负责创建模型并使用绑定模型渲染视图。

控制器是启动器,它决定渲染哪个视图。

赞成的意见:强调单一责任原则高水平的可测试性

欺骗:如果试图在同一控制器中渲染多个视图,有时控制器的工作量太大。

最简单的答案是视图如何与模型交互。在MVP中,视图由演示者更新,演示者充当视图和模型之间的中介。演示者从视图中获取输入,视图从模型中检索数据,然后执行所需的任何业务逻辑,然后更新视图。在MVC中,模型直接更新视图,而不是通过控制器返回。