在MVC模式中为了解耦派生出了controller，service，dao层
1. 在我看来controller是处理权限相关的事情
1. service层是处理业务逻辑以及最重要的事务控制多表插入回滚
1. dao层则是只做操作数据库部分
那么我的两个不同的service如果都要对一个表进行插入操作，
而这个插入又会有多个表的插入复杂的业务，那么这一部分业务应该是放在service（把它称作serviceC）的，
那么问题就是我的serviceA对自己的表进行插入的时候同时要插入C表（和其派生表），
那么我的serviceA是不是应该把serviceC注入进来，还是说思路不对有什么其他方式实现，总不可能同样的逻辑再写一套吧，最主要还是事物的控制。
综合各位意见和大厂意见,service也可以分层,可以分专门处理数据的,处理业务逻辑的,以及多表联动的,这些也是层级调用,本质上还是service,但是命名需要有字的规范
相同的业务放在相同的service，而不是相同的表，如果同时插ac表，那么应该在dao体现，有不同的表。如果一个service对应一个表，叫作什么解耦
事务的传播行为
propagation
1.propagation_required 当前没有事务变创建一个事务，如有有则使用
2.propagation_supports 支持当前事务，有则使用，没有则不使用
3. propagation_mandatory 支持当前事务，有则使用，没有则抛出异常
4.propagation_requires_new 无论有没有，都创建新事务
5.propagation_not_supported 非事务方式提交，有则挂起该事务
6.propagation_never 非事务提交，有则抛出异常
7.propagation_nested 存在事务，在嵌套事务内执行，没有，则创建一个事务
serviceA的传播行为设置为.propagation_nested，具体用哪一中传播行为，你自己可以思量下
service层之间相互调用是不建议的，增加了耦合性，也不能在controller调用不同的service，所以只能在dao层做文章，把调用的方法封装到Dao层
主要看你想要实现什么事情，service不是只是方法的实现或者是接口的传递。mvc模式不是调用dao层的方法吗？
service是业务逻辑层，dao层是数据访问层，所以把数据访问的事情交给dao,serviceA对自己的表进行插入的时候同时要插入C表,那就将DaoC注入进ServiceA就行了
按照我的理解：
1. 首先，MVC 里面应该不包含service的含义，如果操作足够简单，只需要control和dao存取数据就可以了。control涉及的范围比较大，包含处理请求，解析参数，处理业务逻辑和组装返回数据。
2.当control里面的业务逻辑比较复杂，重复的调用比较多，所以才会衍生出service，作用是为了封装相同或者类似的业务逻辑，同时便于拓展和解耦，大多数是为了解耦。解耦的能力需要看service的设计了。
3.问题中说serviceA引用到serviceC的代码，servive是业务逻辑的封装，不是请求访问表的封装，整体的功能应该放到serviceA里才是合适的，同时serviceA会引用daoA和daoC。如果serviceA引用到daoC里的逻辑其他地方也会引用，那本身这是两个业务逻辑，应该分开解耦。
如果业务逻辑很清晰且简单，建议serviceA重写该部分逻辑；如果serviceC逻辑也比较复杂，建议seviceA注入serviceC
看业务吧,因为,有时候插入A表的时候可能会更新缓存数据,这时候,就应该注入serviceA,然后在ServiceA里面添加插入的方法,插入的里面就会更新缓存等等,不同的逻辑,如果只是简简单单的插入的话,直接将daoA注入进来就比较
方便了,所以还是要看业务实际场景,来选择合适的注入方式.并不是单单为了解耦而解耦