三层架构——Controller、Service、Dao
不仅是对代码进行的逻辑分层。其真正的本质，是将业务、技术和数据剥离。搞业务的专心做业务，搞技术的专心搞技术，做数据存储的专心做数据存储。三方通过接口进行对接，任一部分重构，只要输入和输出接口的数据不受影响，就不对其他层造成影响。

三层架构是一种通用型的，面向功能的。具体架设可以结合企业业务的颗粒度进一步细分，增加层数。

我们先来看一下，对于一个项目，比较通用的流程都有什么？
1.接收请求、数据
2.数据合法性验证
3.开启事务
4.执行业务规则、逻辑、流程
5.数据存储
6.事务结束

明显，12可以封装成一个模块，346可以封装，5作为一个模块
划分模块后，就可以做异步了，程序不再是瀑布型，前端不必等业务逻辑全部完成

下面我们通过例子进一步理解

如何理解三层架构？

——服务员、厨子、仓储模型

Controller——接口层（Web层）——服务员

Service——逻辑层——厨师

Dao——数据层——仓储

为什么选择三层架构？

https://www.bilibili.com/list/watchlater?oid=359096349&bvid=BV1PX4y1J7CC&spm_id_from=333.1007.top_right_bar_window_view_later.content.click
对于小公司，沟通成本低，一人多职，效率快响应快，这样很容易做大。可是做大以后呢？项目不在是你一个人的事，需要大家一起来完成。那么，不同人有不同人的思维方式，有不同的编程习惯，而且沟通效率会直线下降，此时，我们就需要对项目进行架构，对编程方式进行规范，对输入输出做详细要求。

和MVC有何不同，为什么有些地方叫Controller为视图层？

MVC的本质思想是：输入View、处理Model、输出Controller。
其解决的问题是，将系统整体整体分类为三个部分，清晰，便于维护。
但事实上耦合性依然很高，各个功能之间的依赖关系很复杂。

三层架构的本质思想是：数据处理放一层，业务逻辑放一层，数据存储放一层。
将业务和数据处理剥离，前端只需要对接Controller就好了，其余的两部分无需因前端改变而改变。

事实上，在三层架构中，Controller充当的角色是网络服务，相较于视图层View，Controller层一般称为接口处层或Web层。
它的职责是接收HTTP请求、解析参数、调用Service层处理业务、根据处理结果组装响应（跳转页面或返回JSON等）。它扮演的是MVC模式中的协调者（Controller） 角色，而不是视图（View）。

三层架构中View的概念被弱化，它不是一个层，而属于一种技术实现，这个渲染过程通常发生在Controller层内部。
1.Controller返回一个逻辑视图名，如 “user-list”
2.然后由视图解析器（View Resolver），如Thymeleaf、FreeMarker去找到对应的模板，如 user-list.html并渲染
3.最终生成HTML返回给浏览器。

三层架构详细拆解

必须坚持

接口层
坚决不写任何业务逻辑代码

逻辑层
不接受任何接口层的容器对象，如request、response、cookie、session。如果哪天我的接口层不采用Web，这些对象就通通没有了
不处理任何数据存储相关的SQL语句，不依赖任何数据层对象。这些对象只有连数据库时候才会有，如果我换成缓存，它们也不复存在。

数据层
不处理任何业务逻辑代码

功能拓展

Web层
如果我想要增加WebService、WebSocket两个功能，我只需要在Web层中增加两个模块就可以了，不对另外两层造成任何影响。
如果我想改用JDBC、JSF、JSP做前端，我只需要改Web层就可以了，不对另外两层造成任何影响。

数据层
如果我们发现，某些数据的访问频度非常大，那么我们引入缓存就好了，只需要在数据层增加一个模块，不对另外两层造成任何影响。

进一步划分

看见这个图有没有什么感觉？
没错，这是流水线的感觉，对于多线程，我们通过进一步细化流程，以提升效率。那么如果我们将小模块聚合成服务，这样就成了微服务架构的雏形。