1.3.3　经典的MVC架构模式

本书中MVC并不是重点，但谈到单体式架构，就不得不介绍MVC，早在1978年MVC的概念就被提出，可以说MVC的出现极大地延缓了单体式架构的衰败时间，它虽然不能从本质上改变单体式架构本身的缺陷，但在很大程度上确实改善了单体式架构代码混乱、难以维护的问题。

MVC将程序简单地划分为3层。

（1）模型层：用于封装与应用程序的业务逻辑相关的数据以及对数据的处理方法。模型有对数据直接访问的权力，如对数据库的访问。模型不依赖视图和控制器，即模型不关心它会被如何显示或如何被操作。除此之外，模型还负责具体的业务逻辑和算法的编写。

（2）视图层：能够实现数据有目的的显示，即将模型处理的数据通过图形界面的形式进行展示，在视图中一般没有程序上的逻辑。

（3）控制层：负责转发请求或对请求的处理，起到不同层面之间的组织作用，用于控制应用程序的流程、页面的跳转等。

MVC的各层之间保持相对的独立，视图不用关心用户的请求和数据的存储，通过不同的控制器可以连接不同的模型和视图来完成用户的需求。多个视图可以共用一个模型，它实现了一种动态的程序设计，使后续对程序的修改和扩展简化，并且使程序某一部分的重复利用成为可能。

MVC各组件之间的具体协作如图1.6所示。

图1.6　MVC协作示意图

由图1.6可以看出，MVC可以让单体式架构的层次更加简单、清晰，代码职责更加独立，虽然不能改变单体式架构本身的结构，但也大大提升了项目代码的可维护性和可复用性。那么，为什么说MVC并不能改变单体式架构本身的结构呢？继续回到图1.5的例子来分析，如果采用MVC的模式，它又将变成什么样子呢？单体式架构MVC结构如图1.7所示。

图1.7　单体式架构MVC结构

由图1.7可以看出，与图1.5相比，其架构进行了很大的优化，先是根据业务的领域或一些边界规则将代码横向拆分成各个模块，然后每个模块内部通过MVC的方式进行了纵向分层。但是，外部单体式的结构并没有改变，所有的代码还在一个容器中运行，所以在1.3.2节中所提到的单体式架构的缺点还是存在的。MVC就像止疼药，只能缓解这些问题，但随着项目的逐渐发展，系统的不断扩大，这些问题还是会暴露出来。这时，急需一种新的模式来从根本上解决这些问题，微服务架构就是这种新的模式。