16

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 来使用悲观锁定而不会引起问题吗？诸如此类的事情.. .)

4

4 回答 4

13

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

如果 JPA 2.0 支持您所需要的，我认为直接使用 Hibernate Core 没有任何优势（而在 JPA 2.0 中，差距变得越来越小，使得回退到 Core 的需要成为例外，而不是规则，这是一个非常好东西）。

我想知道，JPA 2 模型是否真的适合 Hibernate Core 之上而没有任何矛盾？

从 JPA 1.0 开始，Hibernate 开发人员在“考虑 JPA”的情况下创建了 Hibernate3，并在 Hibernate3 中采用了 JPA 语义、默认值等。您可能想在此技术讲座中聆听 Gavin ：Gavin King 关于 Hibernate3 和 EJB3 ：

在本次技术演讲中，King 讨论了 Hibernate3 如何构建和扩展 EJB3，涉及以下主题：

  • Hibernate3 的新特性
  • JBoss中Hibernate3与EJB3容器的关系
  • Hibernate3 与 EJB3 规范的区别
  • Hibernate 的自定义注解在 EJB 之外可用
  • Hibernate 的未来

而且根据我的实践经验，Hibernate 与 EJB 3 并不矛盾这一事实是正确的。

IOW，回退到 Core 总是很容易而且没有问题吗？

无论您是否直接使用 Core，您都在使用它（它EntityManager是Session. 所以，是的，如果你真的需要的话，回到 Core 是很容易的（例如，对于那些仍然不在规范中的东西，比如 Query By Example）。而且，不，这不会导致任何问题（因为您实际上在 JPA 中使用它或它的子集）。

相关问题

于 2010-08-09T15:44:45.997 回答
3

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

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

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

与原生 XML 文件相比，减少映射元数据的代码行数，并且您可能喜欢注释的更好重构能力

JDBC >> Hibernate core >> Hibernate Annotations

...

JDBC >> Hibernate core >> Hibernate EntityManager

JPA 2 更适合 JPA 1 未提供的内容。现在有很多新功能可用，例如

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

等等...

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

于 2010-08-09T14:41:53.647 回答
1

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

我对使用辅助层来访问 Hibernate 核心功能并不感兴趣。就我而言，持久层的可移植性完全不是问题。

JPA API 与 Hibernate API 相比几乎没有真正的优势——我看到人们使用 JPA 命名查询（其中 Criteria 可能会更清晰和更好），并且 JPA 注释设计得更好。

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

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

这种方法在多个主要的商业、政府和遗留数据库重新设计项目中非常成功。简而言之——专注于重要的事情——以及在 API 之上的 API，不是吗。

于 2013-04-06T00:47:55.110 回答
0

使用 JPA api 的好处远远超过使用纯休眠的任何缺点。我不是专家，但我不知道在任何情况下进入休眠状态是有益的。（下拉做纯 JDBC 是另一回事。）

如果有人有任何例子可以分享，我很乐意看到它们。

于 2010-08-09T13:53:06.350 回答