使用Hibernate EntityManager（与Hibernate Core相比）的任何缺点？

Hibernate EntityManager文档说明 ：

根据项目的业务和技术需求，您可以结合使用这三者，没有JPA编程接口和生命周期的注释，甚至是纯本机Hibernate Core。 您可以随时回退到Hibernate本机API，或者如果需要，甚至可以回退到本机JDBC和SQL。

使用JPA API（EntityManager）的代码显然更具可移植性（即使偶尔会回退到Hibernate Core）。

但是在使用纯Hibernate Core时我会有什么优势吗？ 我想知道，如果JPA 2模型真的适合Hibernate Core而没有任何矛盾吗？ IOW，是Core的后备总是容易且没有问题？

我主要担心的是：

也许差异不仅存在于API中，还存在于底层语义中 ？ （例如，可能发生冲突的不同事务/版本控制/锁定语义：在Core文档中提到了悲观锁定，但在EntityManager文档中没有提到 – 所以我仍然可以通过回退到Core而不会导致问题来使用悲观锁定吗？这样的事情…… 。）

Answer 1

但是在使用纯Hibernate Core时我会有什么优势吗？

如果JPA 2.0支持你需要的东西，我认为没有直接使用Hibernate Core的优势（和JPA 2.0一样，差距变得更小，需要回退到Coreexception，而不是规则，这是一个非常好事）。

我想知道，如果JPA 2模型真的适合Hibernate Core而没有任何矛盾吗？

从JPA 1.0开始，Hibernate开发人员创建了Hibernate3，并考虑了“JPA”，并在Hibernate3中采用了JPA语义，默认值等。 你可能想在这个技术讲座中听取Gavin ：Havnate3和EJB3上的Gavin King ：

在这篇技术讲座中，King讨论了Hibernate3如何构建和扩展EJB3 ，解决了以下主题：

• Hibernate3的新function
• Hibernate3与JBoss中的EJB3容器之间的关系
• Hibernate3与EJB3规范的区别在于什么
• Hibernate在EJB外部可以使用自定义注释
• Hibernate的未来

根据我的实际经验，Hibernate与EJB 3不矛盾的事实是正确的。

IOW，是Core的后备总是容易且没有问题？

无论您是否直接使用Core，您都在使用它（ EntityManager是Session的包装器）。 所以，是的，如果你真的需要（对于那些仍然不像规范查询的规范那样的东西），那么回归Core很容易。 并且，不，这不会导致任何问题（因为您实际上在JPA中使用它或其子集）。

相关问题

• 区别Hibernate 3.5 / JPA 2.0

Answer 2

很明显： 取决于您项目的业务和技术需求

但是在使用纯Hibernate Core时我会有什么优势吗？

不要忘记Hibernate Annotations和Hibernate EntityManager都是建立在Hibernate核心之上的。 再来一层了 。 除此之外，它依赖于存储在XML文件中的映射元数据。 有些用户更喜欢使用XML文件而不是注释，因为它使域对象完全独立于您选择的DAO实现。 但是在使用注释时，Hibernate与JPA的书很清楚

与原生XML文件相比，减少用于映射元数据的代码行，并且您可能希望注释具有更好的重构function

 JDBC >> Hibernate core >> Hibernate Annotations 

…

 JDBC >> Hibernate core >> Hibernate EntityManager 

而JPA 2更适合JPA 1未提供的内容。 现在有许多新function，例如

• 面向对象的查询API
• Wrapper的@Embeddable
• @Embeddables @ElementCollection的集合

等等…

不要忘记JPA EntityManager允许您使用getDelegate方法检索其底层供应商特定的提供程序，如果您需要JPA不提供的function。

Answer 3

我喜欢直接使用Hibernate Core。 我也更喜欢XML映射文件。

我真的不想使用辅助层来访问Hibernate核心function。 至于我关心持久层中的可移植性，是一个完整的非问题 。

JPA API相对于Hibernate API的优点很少 – 我看到人们使用JPA命名查询（其中Criteria可能更清晰，更好），JPA注释设计得更好一些。

除此之外，JPA只是增加复杂性和潜在开销的一层 – 没有任何好处。 在这种情况下，在建筑上，正确的决定是反对使用它。

数据库可移植性OTOH非常真实。 我有自定义分配器（生成器），它们是完全可移植的，并且比疯狂的混乱更加高效和简单，这是错误设计的Hibernate。

这种方法在多个主要的商业，政府和遗留数据库重新设计项目上非常成功。 简而言之 – 重点关注什么是重要的 – 以及API之上的API，不是它。

Answer 4

使用JPA api的好处远远超过使用纯hibernate的任何缺点。 我不是专家，但我不知道任何情况下降到hibernate是有益的。 （放下来做纯JDBC是另一回事。）

如果有人有任何分享的例子，我很乐意看到他们。