后端环境中的MVC是什么?

时间:2019-03-14 21:41:51

标签: model-view-controller design-patterns backend

前端的MVC非常合理。但是为什么我们在后端也需要MVC?在这种情况下,给定的后端的“视图”在哪里没有提供任何视觉效果。

2 个答案:

答案 0 :(得分:1)

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

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

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

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

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

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

换句话说,MVC模式适用于两种情况。

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

无论何时应用程序需要接受用户输入,执行某些业务逻辑并呈现某些输出(无论该应用程序是否驻留在一个或多个进程中)以及视图是否存在,MVC都是一种完美有效的模式。一个人会消耗。

答案 1 :(得分:0)

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

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

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

  • 控制人充当中介,并负责接受 来自用户的请求,修改模型(如果需要)并将其转换为 视图。

MVC作为一种模式可以完全存在于后端,也可以完全存在于前端,也可以以其常见的后端和前端组合形式存在。

一个人必须相对思考,看看如何保持所有这三个方面的关注,以便更好地进行应用程序设计。

MVC模式背后的整体思想是代表真实世界实体和表示层数据结构的领域对象之间的清晰区分。域对象应完全独立,并且也应在没有View(数据表示)的情况下工作。换一种说法,在MVC上下文中视图与模型是隔离的。允许将同一模型用于不同的视图。

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

下图描述了所有三个组件如何仅在服务器端(在应用程序容器内部)存在。 仅来自official blog

enter image description here