目录
1.DAO层
全称数据访问层，全称data access object，属于一种比较底层，比较基础的操作。具体到对于某个表、某个实体类的增删改查，即用于数据库的增删改查，表达的是对SQL语句的封装，建议对DAO只做原子操作。有多少张表就有多少个DAO层。在mybatis中，方法主要与xxx.xml内一一对应，相互映射。
Dao层的设计
dao层负责与数据库联络的一些任务封装在此，dao层首先设计dao层接口，然后在配置文件中定义此类接口的实体类，然后就可以在模块中调用此接口来进行数据处理。不需要关心此接口的具体实现类，结构清晰。dao层的数据源配置以及数据库连接参数都在配置文件中进行配置。
2.Service层
全称业务逻辑层，在该层进行复杂的业务逻辑处理，且只专注逻辑处理，即对于多个dao层进行封装、处理。其中需要的数据库操作通过DAO层去实现。所以我们再Service层需要事务管理。
业务逻辑，就是对数据库获取的数据进行处理，比如从数据库获取num=10，逻辑操作是+1，那么+1操作由Service处理。
Service层的设计
Service层，负责业务模块的逻辑应用设计。同样是先设置接口，再设计实现类，接着在配置文件中配置其关联。这样我们就能在应用中调用Service接口来进行业务处理。Service层的业务类具体要调用已经定义的dao层接口。
service层=service接口（可以根据业务复杂程度来省略）+service实现类
设计Service层的优点
我们通过将dao层封装成Service层，让Service层去调用dao层的接口，有利于业务逻辑的独立性和重复利用。程序显得非常简介。
Dao与Service的关系
DAO面向表，Service面向业务。后端开发先数据库设计出所有的表，然后每一张表设计出DAO层，然后根据其具体的业务逻辑将DAO层封装成一个Service层，对外提供一个服务。
3.Colltroler层
Collertroler层俗称控制层，负责请求转发，接收页面（前端H5或者App）传过来的参数，并调用Service层中定义的方法进行业务操作，再将处理结果返回前端。
Collertroler层的设计
Colltroler负责具体业务模块流程的控制，在此层需要调用Service层提供的接口来控制业务流程，控制的配置同样在配置文件中，针对具体的业务流程，有不同的控制器。我们的设计过程可以将流程进行抽象归纳，设计出可以重复利用的单元流程模块，这样可以使程序结构更清晰，大大减少代码量。
4.项目中的具体流程
Controller层调用Service层的方法，Service层调用Dao（mapper）层中的方法，其中调用的参数是使用Entity层进行传递的。总的来说这样每层做什么的分类只是为了使业务逻辑更加清晰，写代码更加方便，所以有时候也需要根据具体情况来，但是大体的都是这样处理的，因为它其实就是提供一种规则，让你把相同类型的代码放在一起，这样就形成了层次，从而达到分层解耦、复用、便于测试和维护的目的。
entity实体层（model），存放的实体类，与数据库中的属性保持一致，实现set和get方法。用于各层（DAO，Service、Colltroler）之间对象数据的封装和传递
