问使用Hibernate还是TomEE？

EN

以下是一些要点：

• Hibernate是一个JPA实现，是三个实现之一。Hibernate的创建者Gavin King在JPA上付出了令人难以置信的努力。从应用程序中移除所有JPA使用是向后移动，而不是向前移动。
• 您可以在带有或不带有TomEE的Tomcat中使用JPA。

就痛恨Java EE并想要远离它而言，这真的成为一项不可能完成的任务。所有这些技术都是Java EE的一部分：

• Servlets
• JSP
• JSF
• JPA
• EJB
• CDI / @Inject
• JAX-RS
• JAX-WS
• JMS
• Bean Validation

将它们中的一些标记为JavaEE，另一些标记为非JavaEE，这是一种否认形式。它们都是作为JavaEE的一部分创建和发布的。

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

为了回答“繁重”和“太多”的问题，在2010年创建了Web配置文件，以便可以在不牺牲可移植性的情况下创建较小的运行时。它包括：

• Servlets
• JSP
• JSF
• JPA
• EJB (lite)
• CDI / @Inject
• Bean Validation

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

• Servlets
• JSP
• JPA
• @Inject
• Bean Validation

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

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

spring框架或JavaEE现在已经足够接近，可以根据您的喜好进行选择(就个人而言，这是JavaEE，但是您更喜欢宝马还是梅赛德斯？:p)

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

这就是说，一旦学到了Java开发，它就会简化很多

所以我的建议是:使用TomEE，如果你发现一些真正阻塞的东西，重写你不想要的东西，但是我相信你会浪费时间的

我不知道TomEE --我想如果您只是想部署到一个不同的J2EE容器中，那么您应该已经这样做了&不需要修改代码。

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

除非您有或将需要“分布式事务”或消息传递支持(例如，来往于IBM大型机)，否则我的观点是J2EE在很大程度上是一个失败的架构。

Tomcat、Spring和Hibernate基本上都是它自己的(不使用JPA包装器或API，它们大多只是从Hibernate最初的成功中复制出来的一个额外的山寨层)。

如果你使用HB config的注解，你可以在代码中使用Hibernate API时使用/组合JPA注解(有时它们有更清晰的语法)。

干杯，希望这能帮上忙。