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

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


当前回答

MVP:观点是主导的。

在大多数情况下,视图会创建其演示者。演示者将与模型交互并通过界面操纵视图。视图有时会与演示者交互,通常是通过某种界面。这归结于实施;您希望视图调用演示者上的方法,还是希望视图具有演示者侦听的事件?归结起来就是:视图了解演示者。视图将委派给演示者。

MVC:控制器负责。

控制器是根据某些事件/请求创建或访问的。然后,控制器创建适当的视图并与模型交互以进一步配置视图。它归结为:控制器创建和管理视图;视图从属于控制器。视图不知道控制器。

其他回答

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

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

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

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

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

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

这是对这些设计模式的许多变体的过度简化,但这是我喜欢思考两者之间差异的方式。

MVC

MVP

鲍勃叔叔的这段视频很好,他在最后简要解释了MVC和MVP。

IMO,MVP是MVC的一个改进版本,基本上可以将你要显示的内容(数据)与你要显示(视图)的方式分开。演示者包含了UI的某种业务逻辑,隐式地规定了应该显示哪些数据,并为您提供了一个哑视图模型列表。当显示数据时,只需将视图(可能包含相同的id)插入适配器,并使用这些视图模型设置相关的视图字段,只需引入最少的代码(仅使用setter)。它的主要好处是您可以针对许多/各种视图测试UI业务逻辑,例如在水平列表或垂直列表中显示项目。

在MVC中,我们通过接口(边界)来粘合不同的层。控制器是我们体系结构的一个插件,但它对显示内容没有任何限制。从这个意义上讲,MVP是一种MVC,其概念是视图可以通过适配器插入控制器。

我希望这有助于更好。

模型视图控制器

MVC是软件应用程序架构的一种模式。它将应用程序逻辑分为三个独立的部分,促进了模块化和易于协作和重用。它还使应用程序更灵活,更易于迭代。它将应用程序分为以下组件:

处理数据和业务逻辑的模型用于处理用户界面和应用程序的控制器用于处理图形用户界面对象和演示的视图

为了更清楚一点,让我们想象一个简单的购物清单应用程序。我们只需要一份本周需要购买的每件商品的名称、数量和价格的清单。下面我们将描述如何使用MVC实现这些功能。

表示器

模型是将在视图(用户界面)中显示的数据。该视图是一个界面,它显示数据(模型)并将用户命令(事件)发送给演示者,以根据该数据进行操作。视图通常引用其演示者。演示者是“中间人”(由MVC中的控制器扮演),并同时引用视图和模型。请注意,“模型”一词具有误导性。它应该是检索或操纵模型的业务逻辑。例如:如果您有一个数据库将User存储在数据库表中,并且您的View希望显示用户列表,那么Presenter将具有对数据库业务逻辑(如DAO)的引用,Presenter将从中查询用户列表。

如果您想查看具有简单实现的示例,请检查此GitHub帖子

从数据库中查询和显示用户列表的具体工作流可以如下所示:

MVC模式和MVP模式有什么区别?

MVC模式

控制器基于行为,可以跨视图共享可以负责确定要显示的视图(前控制器模式)

MVP模式

视图与模型的耦合更加松散。演示者负责将模型绑定到视图。更容易进行单元测试,因为与视图的交互是通过接口进行的通常视图到演示者的映射是一对一。复杂视图可能有多个演示者。

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

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

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

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