什么是MVP和MVC,有什么区别？

Question

当超越RAD(拖放和配置)构建用户界面的方式时,许多工具鼓励您可能会遇到三种设计模式,称为模型 - 视图 - 控制器,模型 - 视图 - 展示器和模型 - 视图 - 视图模型.我的问题有三个部分:

1. 这些模式解决了哪些问题？
2. 它们如何相似？
3. 他们有什么不同？

Answer 1

模型 - 视图 - 演示

在MVP中,Presenter包含View的UI业务逻辑.View中的所有调用都直接委托给Presenter.Presenter也直接与View分离,并通过界面与之对话.这是为了允许在单元测试中模拟View.MVP的一个常见属性是必须进行大量的双向调度.例如,当有人单击"保存"按钮时,事件处理程序将委托给Presenter的"OnSave"方法.保存完成后,Presenter将通过其界面回调View,以便View可以显示保存已完成.

MVP往往是在Web窗体中实现单独呈现的非常自然的模式.原因是View总是首先由ASP.NET运行时创建.您可以找到有关这两种变体的更多信息.

两个主要变化

被动视图:视图尽可能愚蠢,几乎没有逻辑.演示者是一个与视图和模型对话的中间人.视图和模型完全相互屏蔽.模型可能会引发事件,但Presenter会订阅它们以更新视图.在被动视图中没有直接数据绑定,而是View公开了Presenter用于设置数据的setter属性.所有状态都在Presenter中管理,而不是View.

• Pro:最大可测性表面; 清晰分离视图和模型
• Con:更多工作(例如所有setter属性),因为您自己正在进行所有数据绑定.

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

• Pro:通过利用数据绑定,减少了代码量.
• Con:表面上可测试的表面较少(因为数据绑定),并且View中的封装较少,因为它直接与Model进行对话.

模型 - 视图 - 控制器

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

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

MVC的另一个重要区别是View不直接绑定到Model.视图简单地呈现,并且完全是无状态的.在MVC的实现中,View通常不会在后面的代码中有任何逻辑.这与MVP完全相反,因为如果View没有委托给Presenter,它将永远不会被调用.

演示模型

要看的另一种模式是Presentation Model图案.在这种模式中没有Presenter.相反,View直接绑定到Presentation Model.Presentation Model是专为View设计的模型.这意味着此模型可以公开一个永远不会放在域模型上的属性,因为它会违反关注点分离.在这种情况下,表示模型绑定到域模型,并可以订阅来自该模型的事件.View然后订阅来自Presentation Model的事件并相应地更新自身.表示模型可以公开视图用于调用操作的命令.这种方法的优点在于,您可以完全删除代码隐藏,因为PM完全封装了视图的所有行为.Model-View-ViewModel.

有关于演示模型的MSDN文章和WPF(前Prism)的复合应用指南中有关分离演示模式的部分

Answer 2

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

MVC

MVP

Answer 3

我前段时间在博客上发表了这篇文章,引用了托德·斯奈德关于两者之间差异的优秀帖子:

以下是模式之间的主要区别:

MVP模式

• 视图与模型的关系更松散.演示者负责将模型绑定到视图.
• 更容易进行单元测试,因为与视图的交互是通过接口进行的
• 通常一对一地查看演示者地图.复杂视图可能有多个演示者.

MVC模式

• 控制器基于行为,可以跨视图共享
• 可以负责确定要显示的视图

这是我能找到的网上最好的解释.

Answer 4

以下是代表通信流程的插图

Answer 5

MVP是不是一定是这样一个场景,查看负责(见Taligent公司的MVP为例).
我发现不幸的是,人们仍在宣传这种模式(负责观点),而不是反模式,因为它与"它只是一种观点"(实用程序员)相矛盾."这仅仅是一种观点"指出向用户显示的最终视图是应用程序的次要问题.微软的MVP模式使得重复使用Views变得更加困难,并且方便了微软的设计师鼓励不良做法.

坦率地说,我认为MVC的潜在问题适用于任何MVP实现,差异几乎完全是语义的.只要您关注视图(显示数据),控制器(初始化和控制用户交互)和模型(基础数据和/或服务)之间的关注点分离,那么您就可以实现MVC的优势.如果您正在获得好处,那么谁真正关心您的模式是MVC,MVP还是监督控制器？唯一真实的模式仍然是MVC,其余的只是不同的风格.

考虑这篇非常令人兴奋的文章,它全面列出了许多不同的实现.您可能会注意到,他们基本上都在做同样的事情,但略有不同.

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

Answer 6

MVP:视图负责.

在大多数情况下,视图会创建其演示者.演示者将与模型交互并通过界面操纵视图.视图有时会通过某种界面与演示者进行交互.这归结为实施; 您希望视图在演示者上调用方法,还是希望视图包含演示者侦听的事件？它归结为:视图了解演示者.视图委托给演示者.

MVC:控制器负责.

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

Answer 7

MVC(模型视图控制器)

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

MVP(模型视图演示者)

输入以View开头,而不是Presenter.View与关联的Presenter之间存在一对一映射.View包含对Presenter的引用.Presenter也对从View触发的事件做出反应,因此它知道与之关联的View.Presenter根据它在Model上执行的请求操作更新View,但View不支持Model.

有关更多参考

Answer 8

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

用户:点击点击...

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

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

查看:好的,等一下...... [ MVP | MVC ]

(查看调用Presenter | Controller ...)[ MVP | MVC ]

观点:嘿主持人 | 控制器,用户刚刚点击搜索按钮,我该怎么办？[ MVP | MVC ]

主持人 | 控制器:嘿View,该页面上有搜索词吗？[ MVP | MVC ]

观点:是的,......这里是......"钢琴"[ MVP | MVC ]

主持人:谢谢观看,...同时我正在查找模型上的搜索词,请向他/她显示进度条[ MVP | MVC ]

(Presenter | Controller正在调用Model ...)[ MVP | MVC ]

主持人 | 控制器:嘿模型,你对这个搜索词有什么匹配吗？:"piano"[ MVP | MVC ]

型号:嘿Presenter | 控制器,让我查一下...... [ MVP | MVC ]

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

( 过了一会儿 ... )

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

型号:我为你找到了一个列表,Presenter,这里是JSON"[{"name":"Piano Teacher","year":2001},{"name":"Piano","year":1993} ]"[ MVP ]

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

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

主持人:感谢等待观看,我找到了一份匹配结果列表,并以一种可呈现的格式排列:["Piano Teacher 2001","Piano 1993"].请在垂直列表中向用户显示.也请现在隐藏进度条[ MVP ]

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

观点:非常感谢Presenter [ MVP ]

查看:谢谢"控制器"[ MVC ](现在视图正在质疑:我应该如何呈现从模型中获得的结果给用户？电影的制作年份应该是第一个还是最后一个......？应该是在垂直或水平列表？...)

如果你有兴趣,我一直在写了一系列的应对伴随GitHub库的应用程序架构模式(MVC,MVP,MVVP,干净的架构,...)的文章在这里.尽管该示例是为Android编写的,但基本原则可以应用于任何介质.

Answer 9

• MVP =模型 - 视图 - 演示者

• MVC =模型 - 视图 - 控制器

  1. 两种演示模式.它们将模型(思考域对象),屏幕/网页(视图)以及UI的行为方式之间的依赖关系分开(演示者/控制器)
  2. 它们在概念上非常相似,人们根据品味不同地初始化Presenter/Controller.
  3. 关于差异的一篇很棒的文章就在这里.最值得注意的是,MVC模式具有模型更新视图.

Answer 10

另外值得记住的是,MVP也有不同类型.福勒已经将模式分解为两个 - 被动视图和监督控制器.

使用被动视图时,View通常会实现细粒度的界面,其属性或多或少地直接映射到底层UI小部件.例如,您可能拥有一个ICustomerView,其中包含Name和Address等属性.

您的实现可能如下所示:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

您的Presenter类将与模型对话并将其"映射"到视图中.这种方法称为"被动视图".好处是视图易于测试,并且在UI平台(Web,Windows/XAML等)之间移动更容易.缺点是您无法利用数据绑定等功能(在WPF和Silverlight等框架中非常强大).

MVP的第二种风格是监督控制器.在这种情况下,您的View可能有一个名为Customer的属性,然后再将其数据绑定到UI小部件.您不必考虑同步和微观管理视图,监督控制器可以在需要时介入并提供帮助,例如使用编译的交互逻辑.

MVP的第三个"风味"(或者有人可能称之为单独的模式)是Presentation Model(或者有时称为Model-View-ViewModel).与MVP相比,您将M和P"合并"为一个类.您拥有UI小部件所绑定的客户对象,但您还有其他UI特定字段,如"IsButtonEnabled"或"IsReadOnly"等.

我认为我在UI架构中找到的最好的资源是Jeremy Miller在The Build Your Own CAB系列目录中完成的一系列博客文章.他涵盖了MVP的所有风格,并展示了C#代码来实现它们.

我还在YouCard重新访问过的Silverlight环境中发布了有关Model-View-ViewModel模式的博客:实现ViewModel模式.

Answer 11

模型 - 视图 - 控制器

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

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

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

模型 - 视图 - 演示

• 该模型是将在视图(用户界面)中显示的数据.
• 该视图是显示数据(模型)和路线用户命令(事件)给演示根据数据起作用的接口.该视图通常引用其Presenter.
• 该演示是"中间人"(由控制器在MVC饰演),并具有两个,视图和模型引用.请注意,"模型"一词具有误导性.它应该是检索或操作模型的业务逻辑.例如:如果您有一个数据库在数据库表中存储User并且您的View想要显示用户列表,那么Presenter将引用您的数据库业务逻辑(如DAO),Presenter将从该列表中查询列表用户.

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

从数据库查询和显示用户列表的具体工作流程可以这样工作:

有什么区别之间的MVC和MVP模式？

MVC模式

• 控制器基于行为,可以跨视图共享

• 可以负责确定要显示的视图(Front Controller Pattern)

MVP模式

• 视图与模型的关系更松散.演示者负责将模型绑定到视图.

• 更容易进行单元测试,因为与视图的交互是通过接口进行的

• 通常一对一地查看演示者地图.复杂视图可能有多个演示者.

Answer 12

它们各自解决了不同的问题,甚至可以组合在一起,形成如下所示的东西

这里还有MVC,MVP和MVVM的完整比较

Answer 13

这两个框架都旨在分离关注点 - 例如,与数据源(模型)的交互,应用程序逻辑(或将此数据转换为有用信息)(Controller/Presenter)和显示代码(View).在某些情况下,模型也可用于将数据源转换为更高级别的抽象.一个很好的例子是MVC Storefront项目.

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

区别在于,MVC应用程序传统上具有视图,并且控制器与模型交互,但彼此不交互.

MVP设计让Presenter访问模型并与视图交互.

话虽如此,ASP.NET MVC通过这些定义是一个MVP框架,因为Controller访问模型来填充View,这意味着没有逻辑(只显示Controller提供的变量).

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

Answer 14

两者都是试图将表示和业务逻辑分开,将业务逻辑与UI方面分离的模式

在架构上,MVP是基于页面控制器的方法,其中MVC是基于前端控制器的方法.这意味着在MVP标准Web表单中,页面生命周期只是通过从后面的代码中提取业务逻辑来增强.换句话说,页面是服务http请求的页面.换句话说,MVP恕我直言是网络形式的进化类型的增强.MVC另一方面完全改变了游戏,因为在加载页面之前,控制器类拦截了请求,在那里执行了业务逻辑,然后在控制器处理刚刚转储到页面的数据("view")的最终结果中感觉,MVC对于使用路由引擎增强的MVP的监督控制器风格看起来(至少对我而言)很多

它们都能实现TDD并具有缺点和优势.

关于如何选择其中一个的决定恕我直言应该基于投入ASP NET网络表单类型的Web开发的时间.如果一个人认为自己在网络形式上很好,我会建议MVP.如果在页面生命周期等事情上感觉不太舒服,MVC可能是一种方法.

这是另一个博客文章链接,提供了有关此主题的更多详细信息

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

Answer 15

我已经使用了MVP和MVC,虽然我们作为开发人员倾向于关注两种模式的技术差异,但恕我直言中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

Answer 16

在MVP中,视图从演示者绘制数据,该演示者从模型中绘制和准备/标准化数据,而在MVC中,控制器通过视图中的推入从模型中绘制数据并进行设置.

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

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

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

因此,例如,如果模型是汽车,则演示者是某种汽车演示者,将汽车属性(年份,制造商,座位等)暴露给视图.该视图知道名为"car maker"的文本字段需要显示演示者Maker属性.

然后,您可以将视图绑定到许多不同类型的演示者,所有演员都必须具有制作者属性 - 它可以是飞机,火车或者任何视图都不关心的视图.视图从演示者中获取数据 - 无论哪个 - 只要它实现了一个商定的接口.

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

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

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

结论 - MVP和MVC都是UI模式的解耦,但MVP通常使用一个绑定框架,它是下面的MVC.THUS MVP处于比MVC更高的架构级别和MVC之上的包装模式.

Answer 17

MVC（模型-视图-控制器）

\n

在MVC中，控制器是负责人！控制器根据某些事件/请求被触发或访问，然后管理视图。

\n

MVC 中的视图实际上是无状态的，控制器负责选择要显示的视图。

\n

例如：当用户点击\xe2\x80\x9cShow MyProfile\xe2\x80\x9d按钮时，控制器被触发。它与模型通信以获取适当的数据。然后，它会显示一个类似于个人资料页面的新视图。控制器可以从模型中获取数据并将其直接提供给视图（如上图所示），或者让视图从模型本身获取数据。

\n

MVP（模型-视图-演示者）

\n

在 MVP 中，View 才是负责人！每个View都会调用它的Presenter或者有一些Presenter监听的事件。

\n

MVP 中的视图不实现任何逻辑，Presenter 负责实现所有逻辑并使用某种接口与视图进行通信。

\n

例如：当用户单击 \xe2\x80\x9cSave\xe2\x80\x9d 按钮时，View 中的事件处理程序委托给 Presenter\xe2\x80\x99s \xe2\x80\x9cOnSave\xe2\x80\x9d 方法。Presenter 将执行所需的逻辑以及与 Model 进行任何所需的通信，然后通过其接口回调 View，以便 View 可以显示保存已完成。

\n

MVC 与 MVP

\n

\n
• MVC 并不让 View 负责，View 充当 Controller 可以管理和指导的从属角色。
\n
• 在 MVC 中，视图是无状态的，而 MVP 中的视图是有状态的并且可以随时间变化。
\n
• 在 MVP 中，视图没有逻辑，我们应该尽可能让它们保持愚蠢。另一方面，MVC 中的视图可能具有某种逻辑。
\n
• 在 MVP 中，Presenter 与 View 解耦，并通过接口与之对话。这允许在单元测试中模拟视图。
\n
• 在 MVP 中，视图与模型完全隔离。然而，在 MVC 中，视图可以与模型进行通信，以使其保持最新的数据。
\n

\n

\n

Answer 18

我简陋的短视图:MVP适用于大尺度,而MVC适用于小尺度.对于MVC,我有时会觉得V和C可能被看作是单个不可分割组件的两个而不是直接绑定到M,并且当向下到较短的比例时,一个不可避免地会出现这种情况,比如UI控件和基本小部件.在这种粒度级别上,MVP毫无意义.相反,当一个人进入更大的规模时,适当的界面变得更加重要,同样明确的责任分配,这就是MVP.

另一方面,当平台特征有利于组件之间的某种关系时,拇指的这种缩放规则可能非常小,例如与Web相比,它似乎更容易实现MVC,而不是MVP.

Answer 19

MVC有很多版本，这个答案是关于Smalltalk中原始的MVC。简而言之，就是

droidcon NYC 2017 - Clean app design with Architecture Components 的演讲阐明了这一点

Answer 20

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

Answer 21

Uncle Bob有一段精彩的视频，他在最后简要解释了MVC和MVP 。

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

在 MVC 中，我们通过接口（边界）来粘合不同的层。控制器是我们架构的插件，但它没有这样的限制来强加显示什么。从这个意义上说，MVP 是一种 MVC，其概念是视图可通过适配器插入控制器。

我希望这会有所帮助。

Answer 22

我认为 Erwin Vandervalk 的这张图片（以及随附的文章）是对 MVC、MVP 和 MVVM、它们的相似之处和不同之处的最佳解释。由于文章标题中没有包含“MVC”和“MVP”字样，因此该文章不会出现在搜索引擎结果中，用于查询“MVC、MVP 和 MVVM”；但我认为这是最好的解释。

（这篇文章也与 Bob Martin 大叔在他的一次演讲中所说的一致：MVC 最初是为小的 UI 组件设计的，而不是为系统的架构设计的）