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

Question

我正在努力学习网络开发。

我（大部分）了解 MVC 的概念，但我对为什么在服务器端使用 MVC 模型......如 Spring MVC 感到困惑。服务端不是模型和服务，然后是客户端服务、视图和控制器（AngularJS 甚至在客户端明确表示该模式）？

我真的为 MVC 模型如何适应或促进服务器端开发而苦恼。

Answer 1

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

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

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

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

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

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

一清二楚？

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

---

编辑：更多想法。

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

• 在控制器中处理请求。
• 在控制器中构建模型。
• 将模型呈现为“视图”，在这种情况下，它是将模型序列化为 JSON 的视图。

Answer 2

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

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

那么 MVC 是否仍然适用于服务器？是的！只是不一样。服务器通常会生成客户端应用程序运行的初始视图（例如考虑本地化或国际化），并且仍然包含官方模型。但更重要的是，MVC 中的“视图”刚刚发生了变化。服务器端视图不再是 HTML，而是客户端应用程序使用的 JSON 或 XML，而不仅仅是 呈现。

所以为了功能的缘故，我们仍然在服务器上使用 MVC。但为了获得出色的用户体验，我们现在也在客户端使用 MVC。