【发布时间】：2009-08-24 19:15:13
【问题描述】：
当您启动一个新的 Web 应用程序时，您会在 MVC 和 MVP 之间选择哪种模式，为什么？
【问题讨论】：
-
您认为这些模式有什么区别？控制器与演示者有何不同？对我来说，它们是一样的，所以我看不出有什么不同。
【发布时间】：2009-08-24 19:15:13
【问题描述】：
（此答案特定于 Web 应用程序。对于常规 GUI，请参阅 What are MVP and MVC and what is the difference?。）
用于 GUI 应用程序的传统 MVC
这实际上与 Web 应用程序无关，但 MVC 在 GUI 应用程序中的传统工作方式如下：
- 模型包含业务对象。
- 控制器响应 UI 交互，并将它们转发给模型。
- 视图“订阅”了模型，并在模型更改时自行更新。
使用这种方法，您可以有 (1) 多种方式来更新给定的数据，以及 (2) 多种方式来查看相同的数据。但是您不必让每个控制器都知道每个视图，反之亦然——每个人都可以与模型对话。
服务器上的 MVC
Rails、Django 和其他服务器端框架都倾向于使用特定版本的 MVC。
- 该模型为每个数据库表提供大约 1 个类，并包含大部分业务逻辑。
- 视图包含站点的实际 HTML，并且代码尽可能少。基本上，它只是模板。
- 控制器响应 HTTP 请求、处理参数、查找模型对象并将值传递给视图。
这似乎对基于服务器的 Web 应用程序非常有效，我对此非常满意。
客户端上的 MVP
但是，如果您的大部分代码都是用 JavaScript 编写并在 Web 浏览器中运行，那么您会发现现在有很多人在使用 MVP。在这种情况下，角色有点不同：
- 模型仍然包含您业务领域的所有基本实体。
- 视图是一层相当愚蠢的小部件，几乎没有逻辑。
- 演示者在视图小部件上安装事件处理程序，它响应事件并更新模型。在另一个方向上，presenter 监听模型的变化，当这些变化发生时，它会更新视图小部件。因此，presenter 是模型和视图之间的双向管道，它们从不直接交互。
这种模型很受欢迎，因为您可以轻松移除视图层并针对演示者和模型编写单元测试。它也更适合所有内容不断更新的交互式应用程序，而不是处理离散请求和响应的服务器应用程序。
以下是一些背景资料：
- Martin Fowler's encyclopedic summary of MVC, MVP and related approaches.这里有很多美好的历史。
- Martin Fowler's description of "Passive View"，MVP 的变体。
Google 的 MVP + 事件总线
这是video from the Google AdWords team 中描述的一种新方法。它旨在与缓存、离线 HTML 5 应用程序和复杂的客户端工具包（如 GWT）很好地配合使用。它基于以下观察结果：
- 任何事情都可能需要异步发生，因此从一开始就将所有事情都设计为异步的。
- 测试基于浏览器的视图比测试模型和演示者慢得多。
- 您的真实模型数据位于服务器上，但您可能有本地缓存或离线 HTML 5 数据库。
在这种方法中：
- 视图很笨，运行单元测试时可以用模拟对象替换。
- 模型对象只是简单的数据容器，没有真正的逻辑。您可能有多个模型对象代表同一个实体。
- 演示者从视图中侦听事件。每当需要更新或读取模型时，它都会向服务器（或本地缓存服务）发送一条异步消息。服务器通过向“事件总线”发送事件来响应。这些事件包含模型对象的副本。事件总线将这些事件传回给各个演示者，后者更新附加的视图。
所以这个架构本质上是异步的，很容易测试，如果你想写一个 HTML 5 离线应用程序，它不需要大的改变。我还没有使用它，但它是我要尝试的事情列表中的下一个。 :-)
【讨论】：
MVP 和 MVC 都有意义，允许将逻辑与显示分开。
我会选择 MVC，因为它现在广泛用于 Web 开发（Rails，用于 SO 的 .NET MVC），因此我的应用程序将更容易被其他人维护。它也是 - 对我来说 - 更清洁（给予视图的“权力”较少），但这是主观的。
【讨论】：
另一种选择是 MTV，Django 使用的 Model-Template-View。
【讨论】：