MVC模式&三层架构 你搞清楚了么

有人说MVC模式是表现层的架构模式，有人说MVC模式是三层架构的替代方案。那么这两者之间，究竟是什么关系呢？

是什么

三层架构

从概念上来说，三层架构是软件工程领域中的一种架构模式，将业务应用划分为：表现层，业务逻辑层，数据访问层。

表现层：提供交互界面，负责数据的输入与输出。
业务逻辑层：封装业务逻辑，接收表现层的请求，调用数据访问层对数据进行操作，在数据交换中起到承上启下的作用。
数据访问层：负责与数据库进行交互，实现数据的增删查改等操作。

MVC模式

MVC模式同样也是软件工程领域中的一种架构模式，由三部分组成，分别是：模型（Model）、视图（View）和控制器（Controller）。
三层架构在概念上来说是比较清晰的，但是MVC模式相对来说就有些争论了，下面将借助三层架构来解释一下MVC模式，加深我们对MVC模式的理解。

MVC模式&三层架构的关系

MVC模式和三层架构之间的关系存在不同的观点，这是由于对MVC的组成模块的功能理解不同导致的。

有一种观点认为MVC模式是三层架构的替代方案，并对各个模块的功能划分如下：

模型（Model）：可以理解为领域模型（domain model），封装了业务数据和业务逻辑，此时的model对应三层架构中的业务逻辑层和数据访问层。
视图（View）：提供交互界面，负责数据的展示。
控制器（Controller）：负责流程控制，接收输入的数据，委托给相应的model处理，根据结果选择合适的view返回。

其中视图和控制器合起来对应三层架构中的表现层。

另一种观点则认为MVC模式是一种基于表现层的架构模式，区别在于对模型的理解不同，模型的定义如下所示：

模型（Model）：此时的model是数据的载体，类似程序中view model的概念，是view和controller之间通信的载体

在这种观点中，视图，模型，控制器共同组成了三层架构中的表现层，可以认为是对三层架构中的表现层做了进一步的拆分。

通过图2和图3，可以直观的发现，两种观点的差异主要在于对模型的理解不同。如果将MVC模式看做是表现层的架构，其实是对模型做了一个比较狭义的解释，笔者更倾向于认为模型是领域模型的观点。

MVC模式是三层架构的替代方案？

如果将模型认为是领域模型，是否可以将MVC模式看做三层架构的替代方案呢？其实不然，因为在笔者看来，这两者其实是从不同角度对软件工程进行了抽象。

MVC模式强调数据和视图分离，将数据展示和数据处理分开，通过控制器对两者进行组合。

三层架构强调不同维度数据处理的高内聚和低耦合，将交互界面，业务处理和数据库操作的逻辑分开。

既然角度不同也就谈不上互相替代了，反而在日常的开发中可以经常看到两种共存的情况，比如我们设计模型层的时候往往也会拆分出业务逻辑层（service层）和数据访问层（DAO层）。

总结

MVC模式和三层架构分别从不同角度对软件工程进行了抽象，MVC强调数据和展示分离，三层架构强调不同维度数据处理的解耦。两者的目的是相同的，既通过对代码的合理组织，使程序的结构更加直观，降低代码耦合度，加强代码的可扩展性、可复用性、可维护性、灵活性。

公众号文章地址：https://mp.weixin.qq.com/s/Vv_xUYX-uhSo2i7JB4uCBA