service层=service接口+servicelmpl实现类
service层对一个或多个DAO层进行封装，使用一个方法对外表现为实现一个功能。当项目的业务逻辑简单时，可选择service层=service类；当项目的业务复杂时，可选择service层=service接口+serviceImpl实现类，它是作为处理数据用的。
- 处理controller层传过来的数据然后传给给dao层链接数据库进行增删改查，
- 从dao层传过来的数据的处理，比如封装成JavaBean。
对比于controller的作用，具体到数据的操作逻辑，也就是增删改查的操作都应该完整封装到service中。一方面是对于事务的要求，比如一个请求过来，后台需要多步增删改查，一般都要求放到一个service方法中也就是同一段事务里。另一方面也是为了提供统一的接口，有的业务除了本地的controller还会需要服务间通信，比如rest api或者rpc什么的，最后他们都应该从同一个service拿到一致的基础数据，然后由各自的controller按各自的需求加工后返回。
Service层叫服务层，被称为服务，粗略的理解就是对一个或多个DAO进行的再次封装，封装成一个服务，所以这里也就不会是一个原子操作了，需要事物控制，它具体是将dao层的增删改查基本操作调用过来，封装到servce类中，集成一个服务。
controller层
controller层，主要用于给前端返回数据的以及接收前端的数据的，它是业务层，管理用户的操作，用户界面传过的请求，调用对应的服务（service），完成用户请求的处理，而相比较来说service层就是处理业务逻辑。但是在项目中，有时候在控制层也有业务逻辑。
如果业务逻辑代码太薄的话放在controller也没关系。但涉及修改数据的，有事务控制的，需要放service。
总的来说Controler负责请求转发，接受页面过来的参数，传给Service处理，接到返回值，再传给页面。
用途： 控制层，负责具体模块的业务流程控制，需要调用service逻辑设计层的接口来控制业务流程。因为service中的方法是我们使用到的，controller通过接收前端H5或者App传过来的参数进行业务操作，再将处理结果返回到前端。
总结：
个人理解DAO面向表，Service面向业务。后端开发时先数据库设计出所有表，然后对每一张表设计出DAO层，然后根据具体的业务逻辑进一步封装DAO层成一个Service层，对外提供成一个服务。
