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

表示器

在 最有价值球员 ,演示者包含视图的UI业务逻辑。视图中的所有调用都直接委托给演示者。演示者还可以直接从视图中分离出来,并通过接口与之对话。这允许在单元测试中模拟视图。MVP的一个常见属性是必须有大量的双向调度。例如,当有人单击“保存”按钮时,事件处理程序将委托给演示者的“onsave”方法。保存完成后,演示者将通过其界面调用视图,以便视图显示保存已完成。

MVP往往是实现Web表单中独立表示的一种非常自然的模式。原因是视图总是首先由ASP.NET运行时创建。你可以 find out more about both variants .

两个主要变化

被动观点: 该视图尽可能地哑,包含几乎为零的逻辑。演讲者是一个与观点和模型对话的中间人。视图和模型完全相互屏蔽。模型可能会引发事件,但演示者订阅它们以更新视图。在被动视图中,没有直接的数据绑定,相反,视图公开了演示者用来设置数据的setter属性。所有状态都在演示者而不是视图中管理。

• pro:最大可测试性表面;视图和模型的清晰分离
• con:更多的工作(例如所有setter属性)就像您自己做所有数据绑定一样。

监控控制器: 演示者处理用户手势。视图通过数据绑定直接绑定到模型。在本例中,演示者的工作是将模型传递给视图,以便它可以绑定到视图。演示者还将包含手势的逻辑,如按下按钮、导航等。

• pro:通过利用数据绑定,减少了代码量。
• con:由于数据绑定,测试面更少,视图中的封装也更少,因为它直接与模型对话。

模型视图控制器

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

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

MVC的另一个大区别是视图没有直接绑定到模型。视图只呈现,完全无状态。在MVC的实现中,视图通常在代码背后没有任何逻辑。这与MVP相反,因为如果视图不委托给演示者,它将永远不会被调用。

演示模型

另一种模式是 演示模型 模式。在此模式中没有演示者。相反,视图直接绑定到表示模型。表示模型是专门为视图设计的模型。这意味着这个模型可以公开永远不会放在域模型上的属性,因为它违反了关注点的分离。在这种情况下,表示模型绑定到域模型,并可以订阅来自该模型的事件。然后视图订阅来自表示模型的事件,并相应地更新自己。表示模型可以公开视图用于调用操作的命令。这种方法的优点在于,当PM完全封装视图的所有行为时,您基本上可以完全删除代码。这种模式非常适合用于WPF应用程序,也被称为 Model-View-ViewModel .

有一个 MSDN article about the Presentation Model 以及 Composite Application Guidance for WPF (前棱镜)关于 Separated Presentation Patterns

我在博客上引用了 Todd Snyder's excellent post on the difference between the two :

以下是 模式:

MVP模式

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

MVC模式

• 控制器基于行为,可以在 意见
• 可以负责确定要显示的视图

这是我在网上找到的最好的解释。

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

MVC

最有价值球员

以下是表示通信流的图示

MVP是 不 必须是视图负责的场景(例如,请参见Taligent的MVP)。
我发现很不幸的是,人们仍然鼓吹这是一种模式(主管视图),而不是反模式,因为它与“它只是一种视图”(实用程序员)相矛盾。它只是一个视图“声明向用户显示的最终视图是应用程序的次要关注点。微软的MVP模式使得视图的重用变得更加困难,而且 方便地 为微软的设计师提供了鼓励不良行为的借口。

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

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

我个人认为,MVP最近才被重新引入,作为一个吸引人的术语,来减少语义偏执者之间的争论,他们争论什么是真正的MVC,或者证明Microsoft快速应用程序开发工具的合理性。在我的书中,这些理由都不能证明它作为一种独立的设计模式存在。

MVP:视图是负责的。

在大多数情况下,视图会创建其演示者。演示者将与模型交互,并通过接口操作视图。视图有时会与演示者交互,通常通过一些接口。这归结到实现;您希望视图调用演示者的方法,还是希望视图具有演示者侦听的事件?归根结底就是:视图了解演示者。视图委托给演示者。

MVC:控制器负责。

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

MVC(模型视图控制器)

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

MVP(模型视图演示者)

输入以视图开始,而不是演示者。 视图和关联的演示者之间有一对一的映射。 该视图保存对演示者的引用。演示者还对从视图触发的事件做出反应,因此它知道与之关联的视图。 演示者根据其在模型上执行的请求操作更新视图,但该视图不了解模型。

为了更多 Reference

• MVP=模型视图演示者

• MVC=模型视图控制器

  1. 两种表示模式。它们分离了模型(思考域对象)、屏幕/网页(视图)和用户界面的行为(演示者/控制器)之间的依赖关系。
  2. 它们在概念上相当相似,人们根据口味对演示者/控制器进行不同的初始化。
  3. 关于差异的一篇伟大文章是 here . 最值得注意的是,MVC模式具有更新视图的模型。

同样值得记住的是,MVP也有不同的类型。Fowler将该模式分为两种:被动视图和监控控制器。

当使用被动视图时,您的视图通常实现一个细粒度的接口,属性或多或少直接映射到底层的UI小部件。例如,您可能有一个具有名称和地址等属性的ICustomerView。

您的实现可能如下所示:

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

演示者类将与模型对话,并将其“映射”到视图。这种方法被称为“被动视图”。其好处是视图易于测试,并且在UI平台(Web、Windows/XAML等)之间更容易移动。缺点是你不能利用数据绑定之类的东西 真的? 强大的框架,比如 WPF 和 Silverlight )

MVP的第二个特点是监控控制器。在这种情况下,您的视图可能有一个名为customer的属性,然后该属性又被数据绑定到UI小部件。您不必考虑同步和微观管理视图,并且监控控制器可以在需要时介入并提供帮助,例如具有复杂的交互逻辑。

MVP的第三个“特色”(或者有人可能称之为单独的模式)是表示模型(或者有时称为模型视图视图模型)。与MVP相比,M和P“合并”成一个类。你有你的用户对象,你的用户界面小部件是数据绑定到,但你也有额外的用户界面特殊字段,如“isButtonEnabled”或“isReadOnly”等。

我认为我找到的UI架构的最佳资源是Jeremy Miller在 The Build Your Own CAB Series Table of Contents . 他涵盖了MVP的所有风格,并展示了实现它们的C代码。

我还写了一篇关于Silverlight上下文中的模型视图视图模型模式的博客 YouCard Re-visited: Implementing the ViewModel pattern .

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

用户:单击单击

视图 那是什么?[ 最有价值球员 γ MVC ]

用户:我刚点击搜索按钮

视图 :好的,稍等。[ 最有价值球员 γ MVC ]

( 视图 调用 节目主持人 γ 控制器 ) 最有价值球员 γ MVC ]

视图 嘿 节目主持人 γ 控制器 ,一个用户刚刚点击了搜索按钮,我该怎么做?[ 最有价值球员 γ MVC ]

节目主持人 γ 控制器 嘿 视图 ,那个页面上有搜索词吗?[ 最有价值球员 γ MVC ]

视图 :是的,这是钢琴[ 最有价值球员 γ MVC ]

节目主持人 谢谢 视图 同时,我正在查找 模型 ,请给他/她看进度条[ 最有价值球员 γ MVC ]

( 节目主持人 γ 控制器 正在呼叫 模型 ) 最有价值球员 γ MVC ]

节目主持人 γ 控制器 嘿 模型 ,您有这个搜索词的匹配项吗?钢琴 最有价值球员 γ MVC ]

模型 嘿 节目主持人 γ 控制器 ,让我查一下[ 最有价值球员 γ MVC ]

( 模型 正在对电影数据库进行查询)[ 最有价值球员 γ MVC ]

(过了一会儿…)

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

模型 :我为你找到了一个列表, 节目主持人 ,这里是json[“name”:“钢琴老师”,“年份”:2001,“name”:“钢琴”,“年份”:1993][ 最有价值球员 ]

模型 :有一些结果可用, 控制器 . 我在实例中创建了一个字段变量,并用结果填充它。它的名字是“搜索结果列表”[ MVC ]

( 节目主持人 γ 控制器 谢谢 模型 然后回到 视图 ) 最有价值球员 γ MVC ]

节目主持人 :谢谢您的等待 视图 ,我为您找到了一个匹配结果的列表,并以可展示的格式对它们进行了安排:【2001年钢琴老师】、【1993年钢琴】。请在垂直列表中显示给用户。另外,请现在隐藏进度条[ 最有价值球员 ]

控制器 :谢谢您的等待 视图 我问过 模型 关于您的搜索查询。它说它找到了一个匹配结果的列表,并将它们存储在实例中名为“searchresultslist”的变量中。你可以从那里得到它。另外,请现在隐藏进度条[ MVC ]

视图 :非常感谢 节目主持人 [ 最有价值球员 ]

视图 :谢谢“管制员”[ MVC ] (现在 视图 正在质疑自己:我应该如何展示我从中得到的结果 模型 给用户?电影的制作年份应该是第一个还是最后一个…?它应该在垂直还是水平列表中?……)

如果您感兴趣的话,我已经写了一系列关于应用程序体系结构模式(MVC、MVP、MVVP、Clean Architecture…)的文章,并附带了一个Github报告。 here . 尽管该示例是为Android编写的,但其基本原则可以应用于任何媒体。

模型视图控制器

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

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

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

表示器

• 这个 模型 将在视图(用户界面)中显示的数据。
• 这个 看法 是一个显示数据(模型)并将用户命令(事件)路由到演示者以对该数据进行操作的界面。视图通常引用其演示者。
• 这个 节目主持人 是中间人(由MVC中的控制器扮演),对视图和模型都有引用。 请注意,单词model 是误导。它应该是 检索或操作模型的业务逻辑 . 例如:如果您有一个数据库将用户存储在数据库表中,并且您的视图希望显示用户列表,那么演示者将引用您的数据库业务逻辑(如DAO),演示者将从中查询用户列表。

如果您希望看到一个简单实现的示例,请检查 this 吉图布邮报

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

什么是 差异 之间 MVC 和 最有价值球员 模式?

MVC模式

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

• 可以负责确定要显示的视图(前控制器模式)

MVP模式

• 视图与模型的耦合更松散。演示者负责将模型绑定到视图。

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

• 通常视图到演示者将一个映射到一个。复杂视图可能有多个演示者。

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

有个讨论 here 关于MVC与MVP之间的差异。

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

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

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

要了解ASP.NET MVC与MVP的区别,请查看 this MIX presentation 作者:斯科特·汉塞尔曼。

它们各自解决不同的问题,甚至可以组合在一起,产生如下的效果

也有 a complete comparison of MVC, MVP and MVVM here

这两种模式都试图分离表示和业务逻辑,将业务逻辑与UI分离开来。

在体系结构上,MVP是基于页面控制器的方法,而MVC是基于前端控制器的方法。 这意味着,在MVP标准的Web表单页面中,通过从代码背后提取业务逻辑,生命周期得到了增强。换句话说,page是为HTTP请求提供服务的。换言之,MVP IMHO是Web形式的进化增强类型。 另一方面,MVC完全改变了游戏,因为请求在页面加载之前被控制器类截获,在那里执行业务逻辑,然后在控制器处理刚刚转储到页面的数据的最终结果(“视图”)。 从这个意义上讲,MVC(至少对我来说)看起来非常适合监控路由引擎增强的MVP控制器风格。

它们都启用了TDD,并且有优缺点。

关于如何选择其中一个IMHO的决定应该基于一个人在ASP NET Web表单类型的Web开发中投入了多少时间。 如果有人认为自己擅长网络形式,我建议MVP。 如果人们在页面生命周期等方面感觉不太舒服,MVC可能是一种方式。

这里还有另一个博客文章链接,提供了关于这个主题的更多细节。

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

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

在Android中,MVC的版本是MVP: 什么是MVP?

MVP模式允许将表示层与逻辑分离,因此有关接口工作方式的所有内容都与我们在屏幕上表示它的方式分离。理想情况下,MVP模式将实现相同的逻辑,可能具有完全不同和可互换的视图。

首先要澄清的是,MVP不是一个体系结构模式,它只负责表示层。在任何情况下,最好将它用于您的体系结构,而不使用它。

MVP的一个例子是 https://github.com/antoniolg/androidmvp

什么是MVC? MVC体系结构是实现关注点分离的最古老的模式之一。MVC由三层组成,即模型、视图和控制器。

经典的MVC存在于这样一个时代:屏幕上的每个控件/小工具都被认为是哑的,每个控件都与自己的控制器配对,以管理发生在它们上面的用户交互。因此,如果存在10个小工具,那么必须存在10个控制器。在这个场景中,每个小工具都被算作一个视图。Windows GUI系统的出现改变了这一局面。控制-控制器关系已过时。控件获得了响应用户发起的操作的智能。在Windows世界中,视图是所有控件/小工具都存在的表面,因此只需要一个控制器。视图可以接收事件并访问控制器以帮助进行进一步处理。

Android中MVC的示例代码 http://androidexample.com/Use_MVC_Pattern_To_Create_Very_Basic_Shopping_Cart__-_Android_Example/index.php?view=article_discription&aid=116&aaid=138

两者的区别在这里都有 http://www.codeproject.com/Articles/288928/Differences-between-MVC-and-MVP-for-Beginners

现在根据我的经验,你必须在基于Android的项目中使用MVP,因为它增强了MVC模型的版本。

在MVP中,视图从表示器中提取数据,表示器从模型中提取和准备/规范化数据,而在MVC中,控制器从模型中提取数据,并通过在视图中推送进行设置。

在MVP中,您可以使用一个视图来处理多种类型的演示者,也可以使用一个演示者来处理不同的多个视图。

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

在这些框架中,ui/html5/xaml知道presenter的每个ui元素显示的属性,因此当您将视图绑定到presenter时,该视图将查找属性,并知道如何从属性中提取数据,以及当用户在ui中更改值时如何设置这些属性。

因此,例如,如果模型是一辆车,那么演示者就是某种类型的汽车演示者,将汽车属性(年份、制造商、座椅等)暴露在视图中。视图知道名为“Car Maker”的文本字段需要显示Presenter Maker属性。

然后,您可以绑定到视图许多不同类型的演示者,所有这些演示者都必须具有maker属性-它可以是飞机、火车或其他任何视图都不关心的对象。只要视图实现了一个约定的接口,它就从演示者那里提取数据(不管是哪个)。

这个绑定框架,如果你把它去掉,它实际上就是控制器。

所以,你可以把MVP看作是MVC的进化。

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

结论-MVP和MVC都是对UI模式的解耦,但MVP通常使用一个绑定框架,即下面的MVC。因此,MVP比MVC处于更高的体系结构级别,并且是MVC之上的包装模式。

我简陋的短视:MVP适用于大尺度,MVC适用于小尺度。有了MVC,我有时会觉得V和C可能被看作是单个不可分割组件的两面,直接绑定到M上,当向下扩展到较短的范围时,如UI控件和基本小部件,不可避免地会遇到这种情况。在这个粒度级别上,MVP毫无意义。相反,当一个进入更大的范围时,适当的接口就变得更重要了,同样的,明确的职责分配也是如此,MVP出现了。

另一方面,当平台特性倾向于组件之间的某种关系时,这种经验尺度规则的权重可能非常小,比如与Web的关系,在Web中,实现MVC似乎比MVP更容易。

MVC有很多版本,这个答案是关于smalltalk中的原始MVC的。简言之,它是

这次谈话 droidcon NYC 2017 - Clean app design with Architecture Components 澄清它

有 this 来自Bob叔叔的精彩视频,结尾他简要介绍了MVC和MVP。

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

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

希望这样会更好。

最有价值球员

MVP代表模型-视图-演示者。2007年初,微软推出了智能客户端Windows应用程序。

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

视图事件绑定将从视图接口在演示者中实现。

View是用户输入的发起程序,然后将事件委托给Presenter,Presenter处理事件绑定并从模型中获取数据。

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

欺骗: 在实现事件绑定时有点复杂,工作也更多

MVC

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

控制器是发起程序,它决定要呈现哪个视图。

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

欺骗: 有时,如果试图在同一个控制器中呈现多个视图,控制器的工作负载会太大。

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

上面所贴的是人类失败和无法理解两台机器之间最简单握手的总结。我将用常识来解释,试图唤醒你们所有人从这些妄想的理想主义中醒来,这些理想主义在那些想要创造它们的人的头脑中找到了自己的方式。和所有这些过程听起来一样愚蠢,事实是客户机请求的对象模型(即HTML文件)。这就是一切的归宿。

1. 按下一个超链接,客户机向服务器发送一个请求。 服务器通过将对象模型发送到客户机来响应该请求(简称为“响应”)。
2. 服务器通过向客户机发送一个对象模型(HTML文件)来作出响应(称为完全握手)。
3. 客户机浏览器现在可以通过解析、词法/标记化以及将该对象模型标记转换为GUI“视图”来呈现“视图”。

我现在可能退休了,但天哪,你们在争论和辩论完全的胡说八道。老实说,无论您称之为两台机器之间的握手,都不能是单个请求、对象“模型”的单个响应以及最终呈现“视图”的客户机浏览器之外的任何东西。

最后,握手中不存在视图。对象模型只是浏览器通过三个或更多对象模型转换为GUI小部件集和eval方法的标记。HTML、CSS和JavaScript。不管有多少人能说服务器做了一些不同寻常的事情,那就是马粪。

“服务器”不是“控制器”,它是一个定向器,只通过发送对象“模型”响应来定向响应。然后,客户机的浏览器(可能是控制器)从对象“模型”创建“视图”。服务器与此无关。您的计算机语言根本无法进入模型对象,也无法委托它。它只是一个标记创建者。

整个混乱只是一个客户端浏览器“控制器”,它解析“模型”以呈现“视图”或CMV或MCV(按第一顺序作为模型发送),而您无法更改它。但您可以简单地将其称为请求、响应对象模型和呈现视图或rrmv。

很多人都不知道MVC和MVP中的控制器和演示者有什么区别。

它是一个简单的方程

MVC View=MVP的视图和演示者

MVP模型=MVC的控制器和模型

更多信息请参阅 http://includeblogh.blogspot.com.eg/2016/07/the-difference-and-relationship-between.html