为什么在服务器上使用MVC？这不是客户端模式吗？

Question

我正在尝试学习网络开发。

我（大部分）理解MVC的概念，但我很担心为什么在服务器端使用MVC模型......就像Spring MVC一样。服务器端不是模型和服务，然后是客户端服务，视图和控制器（AngularJS甚至在客户端显式显示该模式）？

我真的很挣扎MVC模型如何适应或促进服务器端开发。

Answer 1

MVC是一种模式，不仅仅是Web应用程序。任何具有UI的应用都可以使用MVC模式。

这个想法是你有一个View（html，或者你的操作系统中的一个窗口，甚至一个报告或者其他东西），你有一个代表该视图动态部分的模型。然后你有一个控制器专门处理输入并执行“业务逻辑”来生成模型并将其应用到视图。

所以..例如在服务器上你可能有这个MVC模式：

• 控制器接收HTTP请求并对其进行处理。
• 建立模型
• 该模型应用于视图以生成HTML并将其作为响应发送回来。

在客户端上它会类似（但在Angular的情况下有点不同）：

• 控制器用于确定和操作模型。
• 然后通过指令将模型绑定到您的视图。 （Angular实际上更像是MVVM模式，但它足够相似）
• 视图类似地通过指令绑定到您的模型。 （这是MVVM部分的用武之地。）
• 这里的想法是模型和视图都通过指令保持最新。
• 控制器只包含用于操作模型的“业务逻辑”。

清除泥土？

不用担心。只要知道这一点：这只是一种常见的模式。它不是“特定于服务器”或“特定于客户端”。任何需要将数据清理成模板化输出的内容都可以在任何地方使用它。

---

编辑：更多想法。

对于在服务器上提供JSON（甚至XML）的Web API，在大多数情况下，您仍然使用MVC。这是因为你正在做的是：

• 在控制器中处理请求。
• 在控制器中构建模型。
• 将模型渲染为“视图”，在本例中是一个将其序列化为JSON的视图。

Answer 2

在昔日的好日子里，客户端只是一个展示。服务器负责与模型通信，应用业务逻辑，生成视图以及将静态呈现内容发送回客户端（浏览器）。

随着网络的成熟，其中一些职责从服务器迁移到客户端。现在，服务器端通常是一个像RESTful API这样的薄层，它存储“官方”业务逻辑（而不是客户端上的便利逻辑）并存储模型。但是对于性能和用户体验，客户端现在将模型的副本存储在其自己的模型层中，根据需要与服务器和/或本地存储进行通信，并拥有自己的控制器和视图逻辑以提供令人敬畏的用户体验。 / p>

MVC仍然适用于服务器吗？是!这是不同的。服务器通常生成客户端应用程序运行的初始视图（例如，考虑本地化或国际化），并且仍然包含官方模型。但更重要的是，MVC中的“视图”刚刚改变。而不是服务器端视图是HTML，它现在是客户端应用程序使用的JSON或XML，而不仅仅是呈现。

因此，为了功能，我们仍在服务器上使用MVC。但是为了获得令人敬畏的用户体验，我们现在也在客户端使用MVC。