1

我目前正在使用 Eclipse 进行一个大型项目。通常,作为一个单人团队,这些问题不会成为问题,但由于我们的团队不是一个人,我们需要能够分解项目的各个部分以由某些团队成员进行工作。

简单来说,假设我有两层要分开: 1. 每个 DAO 都是一个单独的 Java 项目,需要单独处理 2. Web 层服务层包含我们所有的服务端点,并且必须能够引用所有的 DAO。该层作为动态 Web 项目在 Tomcat 上运行,并利用 Adob​​e LiveCycle Data Services 作为处理端点创建和管理的部分。

现在,我们遇到的问题是,当我们创建一个 DAO 并单独对其进行单元测试时,它运行良好。但是当我们将它引用到我们的服务项目并尝试运行它时,我们开始遇到与我们有两个不同版本的某些 jar 引用这一事实相关的各种问题,因此我们在运行服务器时开始出现错误。

结果,我们知道我们可以通过拉问题罐并确保将来不再出现问题来解决问题,但正如我之前所说,这是一个多人参与的大型项目,我们不这样做'我们不想花时间在枪下清除依赖问题。

我们正在寻找有关在哪里进行替代解决方案的建议?我们的团队是 JavaEE 的新手,因此对于我们可以使用什么将其中的所有内容捆绑在一起,或者它是否是一个可行的解决方案,我们没有太大的影响。我们是否应该考虑将我们的 DAO 转换为 EJB 并将它们部署在 EAR 库中?如果是这样,我们的服务层在哪里,并且服务层是否能够引用 DAO 类,因为 EJB 维护它自己的类路径(根据我们所读到的内容?)我们是在寻找错误的路径,还是我们完全错了在我们目前对 JavaEE 的理解中?

非常感谢任何帮助。我们仍处于该项目的框架阶段,我们希望确保我们能够长期维护它。

4

3 回答 3

2

我赞同 Maven 的建议。这可以为您的项目结构添加各种理智。

Maven 甚至可以通过mvn eclipse:eclipse

关于 EJB 注释的重要说明。从 ava EE 6 开始,您不再需要将 EJB 与 Servlet 分开,并且可以在 war 文件的同一个 jar 中一起使用它们。

因此,请了解是否使用 EJB 不再像以前那样对打包或类加载器产生任何影响。这些现在是单独的决定。EAR 和类加载器分离现在应该被视为您可能想要使用的功能,如果您想要类加载器分离及其带来的复杂性。大多数应用程序根本不需要它,只需要一个包含 servlet、ejbs、jpa 实体、cdi bean、jaxrs 服务和其他任何您需要的东西的 war 文件就可以了。您可以自由决定如何将它们分开,或者您是否想完全分开它们。

由于事务管理,EJB 确实产生了出色的 DAO,这是您无法从普通 Tomcat 获得的东西,但可以通过TomEE在 Tomcat 中提供,并且在Eclipse中运行良好。您应该出于这个原因考虑 EJB,而不是出于依赖性原因。

旁注,由于您是 Java EE 新手,您可能会发现这很有帮助:

于 2012-05-17T21:58:46.850 回答
2

为了在 1 人以上的团队中使用 Java EE 时有条理,我可以建议:

  • 使用 Maven 管理您的构建过程和库依赖项。

    Maven 有一个小的学习曲线,但是一旦你掌握了它,你会感激不尽。通过使用 Maven,您不再依赖 Eclipse 来管理您的类路径。

    我认为在团队中工作时非常有用的一点是该install功能。假设您正在使用 EJB 模块的 1.0 版本,例如 core-ejb-module-1.0,并且您已将其置于稳定状态并希望项目中的每个人从现在开始都可以参考它。

    然后你在它上面运行一个像这样的 maven 命令:mvn clean package install

    Maven 将清理此模块、编译它、运行测试、创建 jar,然后将其安装到您定义的存储库中。可以是贵公司的任何计算机。

    现在你可以告诉从事其他项目的人在他们的 .pom 文件上更新这个依赖版本,并在他们运行的下一个构建中,在编译之前,maven 将下载这个库然后使用它。真的很整洁。没有更多的类路径地狱。(如本文所述,还有其他方法可以始终自动引用最新的库但有一些警告。无论如何,这只是一个示例。)

  • 使用 JPA/EJB 代替 DAO 模式。

    有人说 DAO 意味着任何类型的数据访问,其他人真正的意思是他们使用 DAO 模式来访问对象。如果是这种情况,则在使用 JPA 时不再需要使用它。(至少对于最常见的情况)。

    就我而言,我有一个通用的 EntityService,它能够对任何实体进行 CRUD 操作,并具有集中的查询管理。然后每个应该执行数据库相关操作的 EJB 都可以注入这个人并完成它的工作。

作为建议,使用 Maven,您的项目可以这样组织:

  • 核心项目结构
    • 核心(pom 根)
    • core-ejb-module(包括所有通用 EJB,例如 EntityService。)
    • core-jpa-module(包括所有 JPA 通用定义,如接口、映射超类等。)
    • core-jsf-module(包括所有 JSF 泛型定义,例如抽象控制器、泛型转换器和 FacesContext 的包装器等。)

现在您已经有了一个核心通用模块设置,您可以创建:

  • 应用结构
    • 应用程序(pom 根)
    • app-ear-module (包括此应用程序中的所有其他模块。共享 jar 位于 ear /lib 文件夹中,因此所有其他模块都可以引用它们。)
    • app-ejb-module-a(包括应用程序业务层的 EJB。它使用 core-ejb-module)
    • app-ejb-module-b (你可能有很多 ejb 模块。你甚至可能有一个只包含 ejb 模块的项目。其他应用程序将通过 Maven 声明它们对它们的依赖。)
    • app-jpa-module(包含代表您数据库表的 JPA 实体的定义。取决于 core-jpa-module)
    • app-web-module(保存此应用程序的页面、控制器和转换器。)

我想你明白了。事物往往是松散耦合的,您可以随意组织项目。

这只是一个简单的例子来说明。我没有解释太多关于 Maven 的内容,但如果您有兴趣,我认为它确实会对您有所帮助。

我希望它能给你一些想法,并可能以任何方式帮助你。

[]的

于 2012-05-17T22:11:09.277 回答
1

如果您可以使用同一组依赖项运行所有子组件,您可能会发现迁移到 Maven 构建会很有帮助。

使用 Maven,您可以定义一个顶级项目,在一个地方管理所有第 3 方依赖项版本,因此所有模块都针对相同的库版本进行构建、测试和部署。您也可能会发现 Maven 非常适合您采用的多模块方法,因为它可以确保在项目的依赖项之一发生更改时正确重建项目。

您仍然可以像以前一样使用动态 Web 项目;Eclipse 将自动将 DAO 部署为服务项目的一部分(IIRC,您需要将 DAO 描述为实用程序模块)。

如果您确实访问了 EJB 根目录,那么您是正确的,每个 EAR 都将获得自己的类加载器,因此可以使用一组不同的依赖项。但是,在您的位置上,我倾向于首先考虑改进您的依赖管理——它可能会更便宜、更容易。

于 2012-05-17T21:33:54.170 回答