常见大型Web项目分层

流行的web框架大多数是MVC框架，MVC这个概念最早是由Trygve Reenskaug在1978年提出，为了能够对GUI类型的应用进行方便扩展，将应用程序进行了3层划分。

1. 控制器（Controller）：负责转发请求，对请求进行处理
2. 视图（View）：洁面设计人员进行图形界面设计
3. 模型（Model）：程序员编写程序应有的功能（实现算法等）、数据专家进行数据管理和数据库设计（可以实现具体的功能）

随着技术的更新换代，大前端时代已然到来，与后端工程一样变得越来越复杂。为了更好的实现工程化，提高开发的效率，主流的方式都是采用前后端分离的模式。这样一来视图（前端）就从MVC中脱离变成了独立的项目，后端就只剩了下了MC这两层了。前端通过调用API接口的方式与后端进行交互。

大多数情况下，我们对模型的理解是有偏差的，比如：有很多公司的项目会在控制器层塞入大量的业务逻辑代码，在模型层只处理数据的存储。问题的根源在于对模型层的字面意思理解，擅自认为这一层就是简单的处理数据的建模，其实这中理解显然是有问题的，业务流程也算是一种“模型”，是对用户行为或者既有流程的一种建模，并非只有按格式组织的数据才能叫模型。

不过按照MVC创始人的想法，我们如果把和数据打交道的代码还有业务流程全部塞进MVC里的M层的话，这个M诚又会显得过于臃肿。对于负载的项目，只有M和C层是远远不够的，比较流程的做法是按照下面的方式进行划分：

1. Controller：服务的入口，负责处理路由、参数校验、请求转发
2. Service：逻辑（服务）层，业务逻辑的入口，从这里开始所有的请求参数一定是合法的。业务逻辑和业务流程也都在这一层中实现，常见的设计中会将该层成为“业务规则”
3. Dao/Repository：主要负责和数据、存储打交道。负责数据的持久化工作，对外暴露接口供业务逻辑层使用

每一层都会做好自己的工作，让后用请求当前的上下文构造下一层工作所需的结构体或其他类型参数，然后调用下一层的函数。在工作完成后，再把处理结果一层层地传出到入口。交互流程如下图：

上述分层绝大多情况下是没问题的，但是当需要支持多种协议（HTTP，gRPC，Thrift）时就不能够很好的适应需求的变化了，因此还需要一个单独的协议层，负责处理各种交互协议的细节，请求流程就会变成下图所示的样子：