这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天
闲扯
查了一些资料，看了一些前辈写的代码，作为一个代码废柴，写写笔记以后回顾。
架构选择
得益于MVC的流行，即使现在已经普及了前后端分离的架构，大部分项目也仍然在内部存在 controllerorhandler、serviceorsvc、daoorrepository这样的划分。
用于隔离数据展示、逻辑处理、数据存取的逻辑。
dao层
dao层主要做数据持久层的工作，负责与数据库进行联络的一些任务都封装在此
注：一般来说我们的项目会使用orm，这层也可以对orm进行一次封装，从而更易使用。由于这层更多的是对数据的通用化处理，所以一般通过代码生成器生成比较方便，比如：gorm。
service层
service层主要负责业务模块的应用逻辑应用设计，这层可能会比较重，也是很考验设计功力的地方，一不留神，就容易把这层变得耦合性极高。
controller层
controller层负责具体的业务模块流程的控制。在此层要调用service层的接口来控制业务流程。一般是入口控制器，做参数接收、转换，返回值处理、协议处理等工作。这一层一般不会太厚，也就是不会有太多的逻辑。这里要注意其与网关（Gateway）的区别，网关要做的事和能做的事会比它多很多。
三者关系
Service层是建立在DAO层之上的，建立了DAO层后才可以建立Service层，而Service层又是Controller层之下的，因而 Service层应该既调用DAO层的接口，又要提供接口给Controller层的类来进行调用，它刚好处于一个中间层的位置。 每个模型都有一个Service接口，每个接口分别封装各自的业务处理方法。 面向接口编程。表示层调用控制层，控制层调用业务层，业务层调用数据访问层。 Dao层设计与设计的数据库表，和实现类（对应的Entity或者JavaBean）一一对应。
