MVP 和 MVC 是什么以及有什么区别？

Question

当超越许多工具鼓励的RAD（拖放和配置）构建用户界面的方式时您可能会遇到三种名为 模型-视图 的设计模式-控制器，模型-视图-Presenter< /a> 和 模型-视图-ViewModel。 我的问题分为三个部分：

1. 这些模式解决了哪些问题？
2. 它们有何相似之处？
3. 它们有何不同？

Answer 1

MVP：视图负责。

在大多数情况下，视图创建其呈现者。 演示者将与模型交互并通过界面操纵视图。 视图有时会与演示者交互，通常是通过某种界面。 这归结为实施； 您希望视图调用演示者上的方法还是希望视图具有演示者侦听的事件？ 归结为：视图了解演示者。 视图委托给演示者。

MVC：控制器负责。

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

Answer 2

MVC（模型视图控制器）

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

MVP（模型视图演示者）

输入从视图开始，而不是演示者。
View 和关联的 Presenter 之间存在一对一的映射。
视图持有对演示者的引用。 Presenter 也会对 View 触发的事件做出反应，因此它知道与其关联的 View。
Presenter 根据它在 Model 上执行的请求操作来更新 View，但 View 不支持 Model。

更多参考

Answer 3

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

用户：单击单击...

查看：那是谁？ [MVP|MVC]

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

查看：好的，请稍等...。 [MVP|MVC]

（View调用Presenter|Controller ...）[ MVP|MVC]

视图：嘿演示者|控制器，用户刚刚点击搜索按钮，我该怎么办？ [MVP|MVC]

演示者|控制器：嘿视图，有吗该页面上的搜索词？ [MVP|MVC]

视图：是的，...这里是...“钢琴”[MVP|MVC]

演示者|控制器：谢谢查看，…同时我正在上查找搜索词模型，请向他/她显示进度条 [MVP|MVC]

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

演示者|控制器 ：嘿模型，您有与此搜索词匹配的任何匹配项吗？：“钢琴”[MVP|MVC]

模型：嘿演示者|控制器，让我检查一下... [MVP|MVC]

（模型 正在查询电影数据库...) [MVP|MVC]

(过了一会儿...)

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

模型：我为你找到了一个列表，演示者< /em>，这里是 JSON 格式“[{"name":"Piano Teacher","year":2001},{"name":"Piano","year":1993}]” [MVP ]

模型：有一些可用的结果，控制器。 我在实例中创建了一个字段变量并用结果填充它。 它的名称是“searchResultsList”[MVC]

（演示者|控制器感谢模型并返回 >查看) [MVP|MVC]

演示者：感谢您的等待查看，我找到了一个为您列出匹配结果，并以合适的格式排列它们：[“钢琴老师 2001”、“钢琴 1993”]。 请以垂直列表的形式向用户展示。 另外请立即隐藏进度条 [MVP]

Controller：感谢等待 View，我已向 Model 询问了您的搜索查询。 它表示它已找到匹配结果列表并将其存储在其实例内名为“searchResultsList”的变量中。 你可以从那里得到它。 另外请立即隐藏进度条 [MVC]

查看：非常感谢演示者 [MVP]

视图：谢谢“控制器”[MVC]
（现在视图正在质疑自己：我应该如何向用户呈现从模型获得的结果？电影的制作年份应该排在第一位还是最后一位...... .？应该在垂直列表中还是水平列表中？...）

如果您感兴趣，我一直在撰写一系列有关应用程序架构模式的文章（MVC、MVP、MVVP、干净架构，...）附有 此处 的 Github 存储库。 尽管该示例是为 Android 编写的，但基本原理可以应用于任何媒体。

Answer 4

MVP不一定是视图负责的场景（例如，请参阅 Taligent 的 MVP）。
我发现不幸的是，人们仍然将其视为一种模式（负责视图）而不是反模式，因为它与“这只是一种视图”（务实程序员）相矛盾。 “这只是一个视图”表明向用户显示的最终视图是应用程序的次要关注点。 Microsoft 的 MVP 模式使视图的重用变得更加困难，并且方便为Microsoft 的设计者提供了鼓励不良实践的借口。

坦率地说，我认为 MVC 的根本问题对于任何 MVP 实现都适用，并且差异几乎完全是语义上的。 只要您遵循视图（显示数据）、控制器（初始化和控制用户交互）和模型（底层数据和/或服务）之间的关注点分离，那么您就可以获得 MVC 的好处。 如果您正在实现收益，那么谁真正关心您的模式是 MVC、MVP 还是监督控制器？ 唯一真正的模式仍然是 MVC，其余的只是它的不同风格。

请考虑这篇非常令人兴奋的文章，其中全面列出了其中的一些内容不同的实现。
您可能会注意到，它们基本上都在做相同的事情，但略有不同。

我个人认为 MVP 最近才作为一个吸引人的术语被重新引入，要么是为了减少语义偏执者之间关于某些东西是否真正是 MVC 的争论，要么是为了证明 Microsoft 快速应用程序开发工具的合理性。 我书中的这些原因都没有证明它作为单独的设计模式的存在是合理的。

Answer 5

模型-视图-控制器

MVC 是软件应用程序架构的一种模式。 它将应用程序逻辑分为三个独立的部分，从而促进模块化以及易于协作和重用。 它还使应用程序更加灵活并欢迎迭代。它将应用程序分为以下组件：

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

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

模型-视图-演示者

• 模型是将在视图（用户界面）中显示的数据。
• 视图是一个界面，用于显示数据（模型）并将用户命令（事件）路由到演示器以根据该数据执行操作。 视图通常有对其 Presenter 的引用。
• Presenter 是“中间人”（由 MVC 中的控制器扮演），并且引用视图和模型。 请注意，“模型”一词具有误导性。 它应该是检索或操作模型的业务逻辑。 例如：如果您有一个在数据库表中存储用户的数据库，并且您的视图想要显示用户列表，那么演示者将引用您的数据库业务逻辑（如 DAO），演示者将从中查询列表用户数。

如果您想查看简单实现的示例，请查看
此 GitHub 帖子

从数据库查询和显示用户列表的具体工作流程可能如下所示：

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

MVC 模式

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

• 可以负责确定显示哪个视图（前端控制器模式）

MVP 模式

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

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

• 通常视图到演示者是一一对应的。 复杂的视图可能有多个演示者。

Answer 6

• MVP = 模型-视图-呈现器

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

  1. 两种呈现模式。 它们分离了模型（认为域对象）、屏幕/网页（视图）以及 UI 的行为方式（呈现器/控制器）之间的依赖关系
  2. 它们在概念上非常相似，人们根据喜好以不同的方式初始化演示者/控制器。
  3. 一篇关于差异的精彩文章是此处。 最值得注意的是 MVC 模式让模型更新视图。

Answer 7

另外值得记住的是，MVP 也有不同类型。 福勒将这种模式分为两种——被动视图和监督控制器。

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

您的实现可能如下所示：

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

您的 Presenter 类将与模型对话并将其“映射”到视图。 这种方法称为“被动视图”。 好处是视图易于测试，并且更容易在 UI 平台（Web、Windows/XAML 等）之间移动。 缺点是您无法利用数据绑定之类的东西（这在 WPF 和 Silverlight）。

MVP 的第二种类型是监督控制者。 在这种情况下，您的视图可能有一个名为 Customer 的属性，该属性再次与 UI 小部件进行数据绑定。 您不必考虑同步和微观管理视图，监督控制器可以在需要时介入并提供帮助，例如使用完整的交互逻辑。

MVP 的第三个“风格”（或者有人可能会称其为单独的模式）是表示模型（或有时称为模型-视图-视图模型）。 与 MVP 相比，您将 M 和 P“合并”为一个类别。 你有你的 UI 小部件数据绑定到的客户对象，但你也有其他特定于 UI 的字段，如“IsButtonEnabled”或“IsReadOnly”等。

我认为我发现的 UI 架构的最佳资源是该系列Jeremy Miller 在 构建您自己的 CAB 系列目录。 他涵盖了 MVP 的所有风格，并展示了实现它们的 C# 代码。

我还在 Silverlight 上下文中撰写了有关模型-视图-视图模型模式的博客 YouCard 重温：实现 ViewModel 模式。

Answer 8

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

有一个讨论此处了解 MVC 与 MVP 之间的差异。

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

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

话虽如此，根据这些定义，ASP.NET MVC 是一个 MVP 框架，因为控制器访问模型来填充视图，而视图没有逻辑（仅显示控制器提供的变量）。

要了解 ASP.NET MVC 与 MVP 的区别，请查看此 MIX 演示文稿 斯科特·汉塞尔曼。

Answer 9

两种模式都试图将表示和业务逻辑分开，将业务逻辑与 UI 方面解耦。

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

它们都支持 TDD，并且都有缺点和优点。

恕我直言，如何选择其中之一的决定应该取决于人们在 ASP NET Web 表单类型的 Web 开发上投入了多少时间。
如果一个人认为自己擅长 Web 表单，我会建议 MVP。
如果人们对页面生命周期等事情感觉不太舒服，MVC 可能是一种选择。

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

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

Answer 10

我已经使用过 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 11

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

在 MVP 中，您可以让一个视图与多种类型的演示者一起工作，也可以让一个演示者与不同的多个视图一起工作。

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

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

因此，如果模型是一辆汽车，那么演示者就是某种汽车演示者，将汽车属性（年份、制造商、座位等）暴露给视图。 该视图知道名为“汽车制造商”的文本字段需要显示演示者制造商属性。

然后，您可以将许多不同类型的演示者绑定到视图，所有演示者都必须具有 Maker 属性 - 它可以是飞机、火车或其他任何东西，视图并不关心。 视图从呈现器中提取数据——无论是哪一个——只要它实现了约定的接口。

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

因此，你可以将 MVP 视为 MVC 的演变。

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

结论 - MVP 和 MVC 都是 UI 模式的解耦，但 MVP 通常使用底层为 MVC 的绑定框架。 因此，MVP 处于比 MVC 更高的架构级别，是 MVC 之上的包装模式。

Answer 12

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

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

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

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

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

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

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

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

MVC 与 MVP

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

Answer 13

我粗浅的看法：MVP 适用于大规模，MVC 适用于小规模。 对于 MVC，我有时觉得 V 和 C 可能被视为单个不可分割组件的两侧，而不是直接绑定到 M，当缩小到较小的规模（例如 UI 控件和基本小部件）时，不可避免地会陷入这种情况。 在这种粒度级别上，MVP 没有什么意义。 相反，当规模更大时，正确的接口就变得更加重要，明确的职责分配也是如此，这就是 MVP。

另一方面，当平台特性有利于组件之间的某种关系时，例如在 Web 中，实现 MVC 似乎比 MVP 更容易，这种经验法则的权重可能很小。

Answer 14

我认为这张图片由 Erwin Vandervalk 拍摄（以及随附的 文章) 是对 MVC、MVP 和 MVVM 及其异同的最好解释。 文章不会出现在有关“MVC、MVP 和 MVVM”查询的搜索引擎结果中，因为该文章的标题不包含“MVC”和“MVP”一词； 但我认为这是最好的解释。

（文章也与Uncle匹配Bob Martin 在他的一次演讲中说：MVC 最初是为小型 UI 组件设计的，而不是为系统的架构设计的）

Answer 15

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

此演讲droidcon NYC 2017 - 使用架构进行简洁的应用设计组件澄清了它

Answer 16

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

Answer 17

有这个来自 Uncle Bob 的精彩视频他在其中简要解释了 MVC 和 最后是MVP。

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

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

我希望这会有所帮助。

Answer 18

您忘记了 Action-Domain-Responder (ADR）。

正如上面一些图表中所解释的，MVC 中的模型和视图之间存在直接关系/链接。
在控制器上执行操作，控制器将在模型上执行操作。 模型中的该操作将触发视图中的反应。
当模型的状态发生变化时，视图始终会更新。

有些人总是忘记，MVC 是在70 年代末，而网络是在 80 年代末/90 年代初才创建的。
MVC 最初不是为 Web 创建的，而是为桌面应用程序创建的，其中控制器、模型和视图将共存。

因为我们使用的 Web 框架（例如：.Laravel）仍然使用相同的命名约定（模型-视图-控制器），所以我们倾向于认为它一定是 MVC，但实际上是别的东西。

相反，请查看 Action-Domain-Responder< /a>.
在 ADR 中，控制器获取操作，它将在模型/域中执行操作。 到目前为止，都一样。
不同之处在于，它然后收集该操作的响应/数据，并将其传递给响应者（例如：view()）进行渲染。
当对同一组件请求新操作时，将再次调用控制器，并重复该循环。
在 ADR 中，模型/域和视图（响应者的响应）之间没有联系。

注意：维基百科指出“每个 ADR 操作都由单独的类或闭包表示。”。 这不一定一定是正确的。 多个Action可以在同一个Controller中，而且模式还是一样的。

mvc adr model-view-controller action-domain-responder

Answer 19

简而言之，

• 在 MVC 中，View 具有 UI 部分，它调用控制器，而控制器又调用模型和模型。 模型依次将事件触发回视图。
• 在MVP中，View包含UI并调用Presenter来实现部分。 Presenter直接调用视图来更新UI部分。
  包含业务逻辑的模型由演示者调用，并且与视图没有任何交互。 所以这里演示者完成了大部分工作:)

Answer 20

MVP

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

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

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

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

优点：
视图只有 UI，没有任何逻辑
高水平的可测试性

缺点：
实现事件绑定时有点复杂，需要更多工作

MVC

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

控制器是发起者，它决定渲染哪个视图。

优点：
强调单一责任原则
高水平的可测试性

缺点：
如果尝试在同一个控制器中渲染多个视图，有时控制器的工作量太大。

Answer 21

模型-视图-演示器

在MVP中，演示器包含视图的 UI 业务逻辑。 所有从 View 委托直接到 Presenter 的调用。 Presenter 也直接与 View 解耦，并通过接口与其进行对话。 这是为了允许在单元测试中模拟视图。 MVP 的一个共同特点是必须有大量的双向调度。 例如，当有人单击“Save”按钮时，事件处理程序将委托给 Presenter 的“OnSave”方法。 一旦保存完成，Presenter就会通过其接口回调View，以便View显示保存已完成。

MVP 往往是在 WebForms 中实现分离表示的非常自然的模式。 原因是视图始终首先由 ASP.NET 运行时创建。 您可以 查找了解有关这两种变体的更多信息。

两个主要变体

被动视图：视图尽可能愚蠢，并且几乎包含零逻辑。 演示者是与视图和模型对话的中间人。 视图和模型是完全相互屏蔽的。 模型可能会引发事件，但演示者订阅这些事件以更新视图。 在被动视图中，没有直接的数据绑定，相反，视图公开演示者用来设置数据的 setter 属性。 所有状态都在 Presenter 中管理，而不是在 View 中管理。

• Pro：最大可测试面； 视图和模型的干净分离
• ：更多的工作（例如所有的 setter 属性），因为您自己进行所有数据绑定。

监督控制器：演示者处理用户手势。 视图通过数据绑定直接绑定到模型。 在这种情况下，演示者的工作是将模型传递给视图，以便它可以绑定到它。 Presenter 还将包含按下按钮、导航等手势的逻辑。

• 优点：通过利用数据绑定，可以减少代码量。
• 缺点：可测试性较差（由于数据绑定），并且视图中的封装较少，因为它直接与模型对话。

模型-视图-控制器

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

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

MVC 的另一大区别是视图不直接绑定到模型。 该视图只是渲染并且完全无状态。 在 MVC 的实现中，视图通常不会在后面的代码中包含任何逻辑。 这与 MVP 相反，MVP 是绝对必要的，因为如果 View 不委托给 Presenter，它将永远不会被调用。

演示模型

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

有一篇 关于表示模型的 MSDN 文章 和 < a href="http://msdn.microsoft.com/en-us/library/cc707819.aspx" rel="noreferrer">WPF 复合应用程序指南（以前的 Prism），关于 分离的表示模式

Answer 22

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

MVC

MVP

Answer 23

我不久前在博客上谈到了这一点，引用了 Todd Snyder 关于两者之间差异的精彩帖子：

以下是两者之间的主要区别
模式：

MVP 模式

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

MVC模式

• 控制器基于行为并且可以跨域共享
  浏览量
• 可以负责确定要显示的视图

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

Answer 24

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