ejb与客户端工件 – 运行时依赖？

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

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

这是否意味着客户端工件应该对impl工件具有runtime依赖性？ 或者是否应该避免这些“循环”依赖，即使一个方向是compile而另一个是runtime ？

Answer 1

这是否意味着客户端工件应该对impl工件具有运行时依赖性？

不，并且没有依赖（或者更好不应该）。 查看客户端工件的类和接口中的import语句，您将看到客户端工件不依赖于实现。

如果客户端依赖于实现，它将违反依赖性反转原则，这是SOLID原则的一部分。

或者是否应该避免这些“循环”依赖，即使一个方向是编译而另一个是运行时？

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

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

编辑

我们的开发人员抱怨说，确保每个客户都有相应的内容是繁琐的手工工作。 一个查找依赖项中的所有客户端工件：列表，添加所有相应的impl工件，再次调用dependency：list，再次添加所有缺少的impl工件等。

我认为他们逐字逐句地了解JEE开发角色 。

软件开发人员执行以下任务以提供包含Java EE应用程序的EAR文件：

• 将在先前阶段中创建的EJB JAR和WAR文件组装到Java EE应用程序（EAR）文件中

• 指定Java EE应用程序的部署描述符（可选）

• validationEAR文件的内容是否格式正确并符合Java EE规范

不过规范也说

汇编程序或部署程序可以直接编辑部署描述符，也可以使用根据交互式选择正确添加XML标记的工具 。

我会说ear是使用工具的assembly描述的一个例子。

JF Meier也提到过

一些开发人员为这个过程编写脚本，但是再次，在一个ejbs的版本更改之后，需要重复该过程，因为可能在依赖树的深处，ejb-clients被删除或添加，因此可能需要额外的impls 。

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

此外……由于耳塞只是一个maven工件，它也可以部署到存储库中。 这比除了作者之外没有人可以访问的私有脚本更好。

我希望这些论点能够在与同事讨论部署策略时帮助您。

Answer 2

您不需要关心客户端对实现的隐式依赖性，因为服务器将管理它。

EJB容器创建一个代理，通过该代理调用实现，因此永远不会从客户端直接引用它。

如果你有包含EJB的pom：

 com.stackoverflow Q43120825-server ejb   javax javaee-api   com.stackoverflow Q43120825-api      maven-ejb-plugin  3.2     

和包含以下内容的EAR文件：

   com.stackoverflow Q43120825-server 1.0-SNAPSHOT ejb   ... other modules    ${project.artifactId}   maven-ear-plugin 2.10.1  7 lib   com.stackoverflow Q43120825-server Q43120825-server.jar  ... other modules that might have the API jar as a dependency      

然后这将在它的lib目录中使用API​​ jar构建一个正确的EAR文件。