java - 循环 EJB 依赖的缺点？

Question

假设我们有两个 EJB ServiceA和 ServiceB . ServiceA提供 ServiceB 中所需的公共(public)方法.同时，ServiceB存在于 ServiceA .

这种循环依赖有什么问题吗？

@Stateless
public class ServiceA implements IServiceA {

  @EJB(mappedName = IServiceB.JNDI_NAME_LOCAL)
  private IServiceB serviceB;

  // ...

  public void foo() {
    // ...
  }
}

@Stateless
public class ServiceB implements IServiceB {

  @EJB(mappedName = IServiceA.JNDI_NAME_LOCAL)
  private IServiceA serviceA;

  // ...

  private void bar() {
    serviceA.foo();
  }
}

我一直试图避免这种架构，但最近一位同事介绍了这种相互使用。我觉得在一个服务中使用一个服务是错误的，它使用第一个服务又使用第二个服务......你明白了。从技术上讲，这显然可行，但我对此并不完全满意，宁愿引入 ServiceC对于 foo()方法。

所以我想知道:

可以有这种循环依赖吗？

如果没有，是否有不这样做的技术原因？

如果在技术上可行，在设计方面是否有任何反对意见？

Answer 1

您的问题超出了 EJB，它是关于类之间的耦合。

Is it okay to have this circular dependency?

不，因为为了防止不必要的可维护性成本上升，如果不需要，两个类应该避免它们之间的强耦合。

在这里你有一个强耦合，因为 A 知道 B，B 知道 A。

If not, are there technical reasons for not doing this?

对于一些 DI 容器，循环依赖的解析可能很复杂，但实际上最严重的问题并不在这里。

对于双向依赖(A 看到 B 和 B 看到 A)，无论我更改 A 或 B :方法(返回的类型和参数)类层次结构等，另一个类都可能受到影响。

例如，在您的代码中，B 使用 foo() A的方法
假设 A 使用 bar() B的方法

如果我更改 foo()通过添加新参数的 A 方法，A 和 B 都被修改，如果我更改 bar() B 的方法通过添加一个新参数，再次修改 A 和 B。
这清楚地表明了类之间的责任定义问题。它鼓励在 future 的变化中混合责任，它降低了代码的可读性和设计的一致性，因此它有利于在修改这些类中的任何一个时产生副作用和回归。

虽然具有单向依赖性(A 看到 B 但 B 没有看到 A)，但如果我更改 A ， B 不会受到影响，因为 B 不知道 A。
所以赞成单向依赖。

Technically, this obviously works, but I'm not entirely happy with it and would rather introduce a ServiceC for the foo() method.

我们没有太多关于执行逻辑的详细信息，但是您引入中间类以避免双向依赖的想法似乎相当不错，因为它可以防止强耦合

如果通过移动 ServiceB 类中的 foo() 方法来更改类的职责是有意义的，那么处理该问题的另一种方法是。这样，如果 serviceB 仅用于调用 foo() 方法，它就不再需要依赖 serviceA。