0

我有一个基于 EJB 的库，需要对其进行修改以与 Tomcat 应用程序服务器兼容（即没有 JaveEE）。我在 Hibernate 上浏览了一下，感到很困惑。

显然，有一个使用 .cfg 文件作为基础的自然 Hibernate 分支，它与 Java SE 兼容，然后有一个基于 JPA 的 Hibernate 分支，它有条件地依赖于 Java EE。我还觉得烦人的一件事是某些接口显然不受支持——例如 CriteriaQuery。

所以我想，我必须去自然的 Hibernate 分支来实现摆脱 Java EE 的目标（考虑到差异，这很烦人）。OTOH，还有兼容 Tomcat 的 TomEE，大概让我保持大部分代码不变

如果我能得到一些反馈，那就太好了。谢谢。

4

3 回答 3

12

几点：

  • Hibernate 是一种 JPA 实现，是三种实现之一。Gavin King，Hibernate 的创建者，在 JPA 上工作非常努力。从应用程序中删除所有 JPA 使用是向后移动，而不是向前移动。你只会失去便携性而没有收获。
  • 您可以在有或没有 TomEE 的情况下在 Tomcat 中使用 JPA。

就讨厌 Java EE 并想摆脱它而言，这确实成为了一项不可能完成的任务。所有这些技术都是 Java EE 的一部分：

  • 小服务程序
  • JSP
  • JSF
  • JPA
  • EJB
  • CDI / @注入
  • JAX-RS
  • JAX-WS
  • 管理系统
  • Bean 验证

将其中一些标记为 JavaEE 而将一些标记为非 JavaEE 是一种否定形式。它们都是作为 JavaEE 的一部分创建和发布的。

解决一些反 JavaEE 营销所造成的混乱几乎是不可能的。真正具有破坏性的是，几乎不可能找到不使用 3 种或更多 JavaEE 技术的“非 JavaEE”应用程序。

为了解决“重”问题和“太多”问题，2010 年创建了 Web Profile，以便可以在不牺牲可移植性的情况下创建更小的运行时。这包括：

  • 小服务程序
  • JSP
  • JSF
  • JPA
  • EJB（精简版）
  • CDI / @注入
  • Bean 验证

没有分布式事务，也没有繁重的东西。如果您堆叠 Tomcat、Hibernate 和 Spring，您将包括：

  • 小服务程序
  • JSP
  • JPA
  • @注入
  • Bean 验证

无论您是否选择使用这些 API，它们都将存在。

使用实现本身但不使用标准 API 几乎没有价值。这是一场虚假的胜利。您仍将使用相同的运行时代码，只是没有可移植性。

于 2012-10-05T18:03:32.130 回答
2

今天， spring框架或 JavaEE 已经足够接近，可以根据您的喜好进行选择（个人认为是 Java EE，但您更喜欢宝马还是梅赛德斯？：p）

也就是说，JPA 规范不是最好的规范，您可以轻松使用特定的行为链接到 hibernate/openjpa/eclipselink，甚至隐藏在 javax.persistence 包后面

据说它使 Java 开发曾经学过的东西轻松很多

所以我的建议：使用 TomEE，如果你发现某些东西真的阻碍了重写你不想要的东西，但 IMO 你会浪费时间

于 2012-10-05T20:37:22.913 回答
0

我不了解 TomEE——我希望如果您只是想部署到不同的 J2EE 容器中，那么您已经这样做了，并且不需要修改代码。

也就是说，这意味着你想远离 EE。

除非您已经或将需要“分布式事务”或消息传递支持（例如，到/来自 IBM 大型机），否则我认为 J2EE 在很大程度上是一个失败的体系结构。

Tomcat、Spring 和 Hibernate 几乎都是独立的（不使用 JPA 包装器或 API，它们大多只是从 Hibernate 最初的成功复制而来的额外盗版层）是我推荐的。

如果您为 HB 配置添加注释，则可以在代码中使用 Hibernate API 时使用/组合 JPA 的注释（有时它们具有更清晰的语法）。

干杯，希望这会有所帮助。

于 2012-10-02T02:45:32.070 回答