后端上下文中的 MVC 是什么？

Question

前端的 MVC 非常有意义。但是为什么我们在后端也需要 MVC 呢？在这种情况下，“视图”在哪里，因为后端不提供任何视觉效果。

Answer 1

MVC 是一种促进关注点分离的设计模式，其中三个参与关注点是 •

• 模型是一种保存业务数据的数据结构，并且是 从一层转移到另一层。

• 视图，负责显示存在于 应用程序或将其视为数据结构（完全解耦 来自模型）仅用于演示目的（不需要 演示输出本身）例如查看下图中的模板

• 控制者充当调解人，负责接受 来自用户的请求，修改模型（如果需要）并将其转换为 视图。

MVC作为一种模式可以完全存在于后端，也可以完全存在于前端，或者以后端和前端结合的常见形式存在。

人们必须进行相对思考，看看如何让所有这三个问题保持独立，以实现更好的应用程序设计。

MVC 模式背后的整个理念 是在表示现实世界实体的领域对象和表示层数据结构之间非常明确的分离。域对象应该是完全独立的，并且应该在没有视图（数据表示）的情况下工作。或者其他的思考方式是，在 MVC 上下文中，视图与模型是隔离的。它允许使用具有不同视图的相同模型。

Spring MVC 是后端 MVC 框架的一个很好的例子。

下图描述了这三个组件如何仅存在于服务器端（在应用程序容器内）。 仅取自official blog。

Answer 2

MVC 是关于在接受用户输入、执行业务逻辑和呈现输出的应用程序中分离关注点。它没有说明该逻辑在哪里。它也没有指定所有逻辑必须存在于单个进程中。

MVC 的一个相当传统的用法是使用电子表格。让我们看看单进程应用程序和多进程应用程序，看看它们如何实现这个简单的电子表格：

     A     B       C
   ----- ----- ---------
1 |  1     2    =A1+B1

假设用户在单元格A1 中输入数字4。会发生什么？

单进程应用程序（例如 Microsoft Excel）：用户输入由视图逻辑处理，直到用户离开单元格。一旦发生这种情况，控制器就会收到一条消息，用新值更新模型。该模型接受新值，但还运行一些业务逻辑来更新受更改影响的其他单元格的值。完成后，模型会通知视图其状态已更改，并且视图会呈现新状态。正如@jaco0646 所建议的那样，该通知可以通过 pub/sub 进行，但也可以通过回调来处理。

多进程应用程序（例如 Google 表格）：用户输入由视图逻辑（在客户端）处理，直到用户离开单元格。一旦发生这种情况，控制器（在服务器上）会收到一条消息（通过 HTTP 或套接字）以使用新值更新模型（也在服务器上）。该模型接受新值，但还运行一些业务逻辑来更新受更改影响的其他单元格的值。完成后，模型会通知视图其状态已更改，并且视图会呈现新状态（在客户端中）。该通知可以通过控制器的 HTTP 响应或通过套接字发生。

换句话说，MVC 模式适用于这两种场景。

此外，将客户端和服务器视为两个完全独立的应用程序也是完全有效的，它们都可能实现 MVC。在这种情况下，客户端的模型和服务器的视图都不那么传统。客户端的模型可能会向服务器发出 AJAX 请求，而不是自己运行复杂的业务逻辑或在本地保存数据。而且，服务器的视图很可能是一个序列化程序，它产生某种形式的客户端可以理解的结构化输出，例如 JSON、XML 甚至 CSV。

无论何时应用程序需要接受用户输入、执行一些业务逻辑和呈现一些输出——无论该应用程序是否存在于一个或多个进程——以及无论视图是否是某种东西，MVC 都是一种完全有效的模式人类会消费。