java为什么要分为service层，dao层，controller层？

入行前我也觉得似乎没必要分这么多层，至少service层似乎没什么必要，controller层么，毕竟是用来配合框架帮助我们解析request以及把我们的返回的数据封装成response的，dao层呢，框架帮我们写好了很多很实用的快速增删改查的方法，也很实用。那么中间这一点代码直接controller里不就行了吗，为什么还专门要一个service层呢？

但是入行后我遇到了一个很基本的需求，就明白了service层确实还是有用的。需求是这样子的，数据库里有公司（business）,部门（deparment），和员工（employee）三个表。从名字就能看出来，这三个表是有依赖关系的。员工依赖于部门，部门依赖于公司。简直就是真香打脸下场

什么是三层架构？

三层架构是指：视图层View、业务逻辑层Service、数据访问层DAO。他们分别完成不同的功能。

View层：用于接收用户提交请求的代码

Service层：系统的业务逻辑主要在这里完成

DAO层：直接操作数据库的代码

为了更好的降低各层之间的 耦合度（系统的复杂度，在三层架构程序设计中，采用面向抽象变成。即上层对下层的调用，是通过接口实现的。而下层对上层的真正服务提供者，是下层接口的实现类。服务标准（接口）是相同的，服务提供者（实现类）可以更换。这就实现了层间解耦合。

（发生在哪一层的变化，只需更改该层，不需要更改整个系统。层次清晰，分工明确，每层之间耦合度低——提高了效率，适应需求变化，可维护性高，可扩展性高）

Controller是管理业务（Service）调度和管理跳转的。Service是管理具体的功能的。Controller只负责管理，而Service负责实施。

DAO只完成增删改查，虽然可以1-n，n-n，1-1关联，模糊、动态、子查询都可以。但是无论多么复杂的查询，dao只是封装增删改查。至于增删查改如何去实现一个功能，dao是不管的。

总结这三者，通过例子来解释：

Controller像是服务员，顾客点什么菜，菜上给几号桌，都是ta的职责；

Service是厨师，action送来的菜单上的菜全是ta做的；

Dao是厨房的小工，和原材料打交道的事情全是ta管。

相互关系是，小工(dao)的工作是要满足厨师(service)的要求，厨师要满足服务员(controller)转达的客户（view）的要求，服务员自然就是为客户服务喽。

加入你换成SpringWebFlux，响应式代码，这时候代码都是 Reactive Streams，如果代码组织好这3个层都可以在一个 Streams 中完成，这时候就没有多大必要看重划分这 3个层了。

另外，其他的异步非阻塞web框架（node.js、vert.X），它们的黄金准则是不要阻塞事件循环——对应上面的就是控制器里的代码不能是同步阻塞执行的。它们是事件驱动的，比如 vert.X 你要是想获取一个 “100个回答”，你应该向事件总线地址 “GET_100_ANSWERS_ADDRESS”发送一个事件，传一个回调函数，等事件响应后处理返回的结果写入Response。这个事件总线地址上你应该注册一个消费者，处理事件，返回 “100个回答"。

Web开发无论怎么分层都是为了更好的组织代码，逻辑清晰、灵活、易阅读、扩展性高。Go非面向对象可以做Web开发，Node.js 单线程异步也可以做Web开发，Java同步阻塞可以做Web开发，Java异步响应式也可以做Web开发，它们的代码组织方式也都不同。