在ssh2开发中，请问在service层中注入其他service类是否破坏了系统的架构？

Question

我的系统后台是model，dao,service三层，我知道一般都是在service中注入dao类，但我想在某类的service中做其他类的操作，我想直接注入其他类的service，因为我想调用的其他类的那个service的方法已经用dao实现好了，而且逻辑也比较复杂，如果注入的是其他类的dao那岂不是又要重写一遍逻辑？我想问注入service是否破坏了系统架构？

Answer 1

没必要啊，你注入其他类的service不也最终调用对应service的dao方法吗，只要在这个service中声明一个对应的dao就行了，没必要这么弄的，spring依赖注入本来就是为了降低耦合度的，虽然没试过，这样的话感觉肯定不符合这种理念了

Answer 2

如果我想调用的service已经用dao实现了比较复杂的逻辑了，这时候还是只注入dao岂不是又要把逻辑重写一遍？

Answer 3

要不把待调用的service直接写在service中用单例模式实例化，一个两个不会影响整个框架。

Answer 4

如果我想调用的service已经用dao实现了比较复杂的逻辑了，这时候还是只注入dao岂不是又要把逻辑重写一遍？ 你的逻辑不要写在DAO,DAO只做干净的增删改查，比如你有数据要插入数据库，但要先把数据做点逻辑或转换之类的事写在service层就可以了。service调service没问题。

Answer 5

觉得完全是没问题的，程序反应的是现实生活中的问题，现实生活中一些复杂的业务也是由一些零散的业务组合而而成,一个service里面的一个方法就是一个业务。其实这样做的唯一需要考虑的东西是事务是否同步的问题，比如在spring里面声明了两个service层A和B里面的方法都是受事务管理的，你现在从A里面调用了B到底事务是算哪一个，万一你的A里面的B调用后事务提交了而在A里面还有其它业务这时候其他业务产生了错误，那么事务就没有同步了那怎么办，那么你这个业务就错了。但是事实证明这个业务不是这么算的，这时候这个事务是算做A里面的事务。个人理解其实就是采用了代理模式在你调用A方法的外面封装了事务的开启和提交的代码。所以你这种方式完全是可以的，公司的封装的一些方法也是这么做的，这样可以让dao层只有一个类不用每个实体都来一个dao的接口和类。