有两种理解：
1.Dao调用数据库，Service分模块调用各自Dao，Controller分模块调用Service，根据功能不同选择调用单/多个Service，所以这时事务放在Controller层，因为放到各自Service相当于无事务；
2.Dao调用数据库，Service是根据业务需求/逻辑不同对单/多个Dao的进一步封装，即真正意义上的“服务”，所以相互之间也可调用提高复用性，Controller负责请求转发和结果返回等，所以这时事务放到Service层；
举个列子：
controller：接收参数，告诉service层我要删这个角色，并且返回结果
service：负责处理删角色的逻辑，也就是删完角色还要删用户
dao：负责把service交代的东西真正的删掉
分层理解：
一：Dao(Data Access Object):数据存储对象
不管是什么框架，我们很多时候都会与数据库进行交互。如果遇到一个场景我们都要去写SQL语句，那么我们的代码就会很冗余。所以，我们就想到了把数据库封装一下，让我们的数据库的交道看起来像和一个对象打交道，这个对象通常就是DAO。当我们操作这个对象的时候，这个对象会自动产生SQL语句来和数据库进行交互，我们就只需要使用DAO就行了。
DAO层叫数据访问层，全称为data access object，属于一种比较底层，比较基础的操作，具体到对于某个表的增删改查，也就是说某个DAO一定是和数据库的某一张表一一对应的，其中封装了增删改查基本操作，建议DAO只做原子操作，增删改查。
通常我们在DAO层里面写接口，里面有与数据打交道的方法。SQL语句通常写在mapper文件里面的。
二：Service：服务
服务是一个相对独立的功能模块，主要负责业务逻辑应用设计。首先也要设计接口，然后再设计其实现该接口的类。这样我们就可以在应用中调用service接口进行业务处理。service层业务实现，具体调用到已经定义的DAO的接口，封装service层的业务逻辑有利于通用的业务逻辑的独立性和重复利用性 。
Service层叫服务层，被称为服务，粗略的理解就是对一个或多个DAO进行的再次封装，封装成一个服务，所以这里也就不会是一个原子操作了，需要事务控制。
三：Controller：控制器
主要负责具体业务模块流程的控制，会调用Service层的接口来控制业务逻辑。Controler负责请求转发，接受页面过来的参数，传给Service处理，接到返回值，再传给页面。
总结：
DAO面向表，Service面向业务。后端开发时先数据库设计出所有表，然后对每一张表设计出DAO层，然后根据具体的业务逻辑进一步封装DAO层成一个Service层，对外提供成一个服务。
在实际开发中的Service层可能被处理为实体Service层，而不是接口，业务逻辑直接写在Service（Class，不是Interface）层中，Controller直接调用Service，Service调用Mapper。
Service之间也是可以互相调用！
参考：
https://blog.csdn.net/Fire_Sky_Ho/article/details/82193911
