java service层调用service影响效率吗

Posted 2023-05-15

或者说service层调用service具有什么弊端？

不会影响效率,但是会使逻辑混乱增加耦合度,为代码维护带来困难 参考技术A 可以实现，代码也不会报错，但是不符合规范，当别人看你代码，或者是你自己过一段时间再看，可能不是那么好理解，增加了阅读的难度，而且不利于使用代码生成器生成代码，建议还是规范点写。我们对于JAVA初学者和自学者，对JAVASE、JAVAEE和三大框架进行辅导,如果需要详细了解，请查看我资料的网址连接，我们一定耐心为你解答。 参考技术B 效率必须变低。
service层，如果再发请求去进行服务，还不如在原来的service里面，直接调用你要处理的service的处理方法。
毕竟，在service层在请求service服务这里，就是是service-》请求-》调用service的方法，还不如直接就service-》调用你需要的service服务本回答被提问者和网友采纳

facade service 层有啥作用

传统的J2EE系统的分层，一般是WEB展示层、Web控制层、业务逻辑层、数据访问层。
各层的职责比较简单，控制层仅处理Web参数与数据并传递给业务逻辑层。而具体的业务逻辑放在Service层即业务逻辑层中。同时，事务的控制边界也在这一层。Dao层对数据库的操作，更简单的理解为对SQL的拼装。
上面的各层泛泛来讲，都容易理解。具体用法上，又会有一些延伸。比如说Dao层，有的由一组Dao类来实现，有的则只有统一的Dao。这里的Dao类似一个工具类。比如使用ibatis2的时候，Dao可能只是一个Client及对应的xml。

问题:
在具体实施后，存在一些问题。往往一开始开发的时候，需求比较简单，各表都只需要增删改查。所以，往往类的创建往往是数据库导向的。即一张表对应一个Dao类/接口，进而又对应一个Service类/接口。
随着开发的继续，需求的补充，一些主业务表的Service往往贯穿整个业务系统的流程。自然而然，业务逻辑的代码开始膨胀。结果是主业务表的Service类异常的庞大。

因为领域模型是一个充血的模型，而目前传统的分层属于贫血的模型，转换差别比较大。如果是在原有的贫血模型基础上，再加入Facade层。
可是Facade层跟Service层到底有什么差别呢？如果没有严格的规则的话，最后只会导致Facade层是一个空壳。 参考技术A

使用Facade模式的是为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

将一个系统划分成为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小。达到该目标的途径之一是就是引入一个外观（Facade）对象，它为子系统中较一般的设施提供了一个单一而简单的界面。将各个子系统整合起来作为Facade，提供给客户端使用。

适用情况：

当你要为一个复杂子系统提供一个简单接口时。

客户程序与抽象类的实现部分之间存在着很大的依赖性。

当你需要构建一个层次结构的子系统时，使用Facade模式定义子系统中每层的入口点。仅通过facade进行通讯。