您会选择哪种模式用于Web应用程序？为什么？

Question

当您启动新的Web应用程序时，您在 MVC 和 MVP 之间选择哪种模式以及为什么？

Answer 1

（此答案特定于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。在这种情况下，角色有点不同：

• 该模型仍包含业务域的所有基本实体。
• 视图是一层相当愚蠢的小部件，几乎没有逻辑。
• 演示者在视图窗口小部件上安装事件处理程序，它响应事件并更新模型。在另一个方向上，演示者侦听模型的更改，并在发生这些更改时更新视图窗口小部件。因此，演示者是模型和视图之间的双向管道，它永远不会直接交互。

此模型很受欢迎，因为您可以轻松删除视图层并针对演示者和模型编写单元测试。它也更适合于一切都在不断更新的交互式应用程序，而不是处理离散请求和响应的服务器应用程序。

这是一些背景阅读：

• 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等复杂的客户端工具包配合使用。它基于以下观察：

1. 任何可能需要异步发生，因此从一开始就将所有内容设计为异步。
2. 测试基于浏览器的视图比测试模型和演示者慢得多。
3. 您的真实模型数据存在于服务器上，但您可能拥有本地缓存​​或脱机HTML 5数据库。

采用这种方法：

• 视图非常愚蠢，您可以在运行单元测试时将其替换为模拟对象。
• 模型对象只是数据的简单容器，没有真正的逻辑。您可能有多个模型对象代表同一个实体。
• 演示者从视图中侦听事件。每当需要更新或从模型中读取时，它都会向服务器（或本地缓存服务）发送异步消息。服务器通过向“事件总线”发送事件来响应。这些事件包含模型对象的副本。事件总线将这些事件传递回各个演示者，这些演示者会更新附加的视图。

因此，这种体系结构本质上是异步的，它易于测试，如果您想编写HTML 5离线应用程序，则不需要进行重大更改。我还没有使用它，但它是我要尝试的事项列表中的下一个。 ： - ）

Answer 2

MVP和MVC都有意义，允许将逻辑与显示分开。

我会选择MVC，因为它最近在Web开发中被广泛使用（Rails，.NET MVC用于SO）所以我的应用程序将更容易被其他人维护。它也是 - 我更清洁（给视图的“权力”），但这是主观的。

Answer 3

另一种选择是Django使用的MTV，Model-Template-View。