java - 带有客户端 Artifact 的 ejb - 运行时依赖性？

Question

我们公司在两个 Artifact 中创建一个ejb。 impl Artifact 包含实现，客户端 Artifact 包含所有接口(interface)。这意味着 impl Artifact 对客户端 Artifact 具有编译依赖性。

现在在运行时，客户端 Artifact 需要 impl Artifact - 否则容器无法注入(inject)所需的对象。这意味着耳朵需要包含所有客户端 Artifact 的 impl Artifact 。

这是否意味着客户端 Artifact 应该对 impl Artifact 具有 运行时 依赖性？还是应该避免这些“循环”依赖，即使一个方向是编译，另一个是运行时？

Answer 1

Does this mean that the client artifact should have a runtime dependency on the impl artifact?

不，没有依赖性(或者更好的是不应该)。查看客户端 Artifact 的类和接口(interface)中的导入语句，您会发现客户端 Artifact 不依赖于实现。

如果客户端依赖于实现，它将违反作为 SOLID 一部分的依赖倒置原则。原则。

Or should these "circular" dependencies be avoided, even if one direction is compile and the other is runtime?

其实运行时是需要实现的，但那是组件组装的问题。人们可能希望某天或出于测试原因替换实现。因此，将客户端 Artifact 中的 Maven 依赖项引入到实现中只是为了使组件组装更容易一点并不是一个好主意。

相反，您应该在 EAR 部署单元中声明实现依赖性，因为 EAR 是企业应用程序的组件。

编辑

Our developers complain that making sure that every client has a corresponding impl in the ear is tedious manual work. One looks for all client artifacts in the dependency:list, adds all corresponding impl artifacts, calls dependency:list again, adds again all missing impl artifacts etc.

我认为他们采取了 JEE development roles逐字描述。

A software developer performs the following tasks to deliver an EAR file containing the Java EE application:

• Assembles EJB JAR and WAR files created in the previous phases into a Java EE application (EAR) file

• Specifies the deployment descriptor for the Java EE application (optional)

• Verifies that the contents of the EAR file are well formed and comply with the Java EE specification

尽管如此，规范还说

The assembler or deployer can edit the deployment descriptor directly or can use tools that correctly add XML tags according to interactive selections.

我会说 ear pom 是使用工具进行程序集描述的示例。

JF Meier 也提到了

Some developers write scripts for this process, but then again, after one changes versions of some ejbs, one needs to repeat the process because maybe somewhere deep down in the dependency tree, ejb-clients were erased or added, so additional impls might be necessary.

对我而言，这些脚本与 ear pom 相同。也许更灵活，但以标准和惯例为代价。他们必须在每个版本中更新脚本这一事实清楚地表明，如果这些版本也由 maven 更新会更好。

此外... 由于 ear pom 只是一个 maven Artifact ，它也可以部署到存储库中。这比除作者之外没有人可以访问的私有(private)脚本要好。

希望这些论点对您与同事讨论部署策略时有所帮助。