使用Hibernate EntityManager（与Hibernate Core）的任何缺点？ [英] Any drawbacks of using Hibernate EntityManager (vs. 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？ ）

解决方案

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

如果JPA 2.0支持你所需要的，那么在我看来，直接使用Hibernate Core没有什么好处（并且在JPA 2.0中，差距变得更小，使需要回退到核心例外，而不是规则，这是一件非常好的事情）。

我怀疑，如果JPA 2模型真的符合Hibernate Core的顶部而没有任何矛盾？

自从JPA 1.0开始，Hibernate开发人员创建了带有JPA的Hibernate3，并在Hibernate3中采用了JPA语义，缺省值等。您可能想在此技术讲座：加文金在Hibernate3和EJB3上听加文
$ b

在这篇技术演讲中，King将讨论 hibernate3如何构建并扩展
EJB3 ，可解决以下主题：

• Hibernate3的新功能


• 在Hibernate3和JBoss中的EJB3容器之间


• Hibernate3与EJB3规范的不同之处


• Hibernate在EJB外部可用的自定义注释
  
• Hibernate的未来

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

IOW，是一款可以轻松回退并且没有问题的Core？

是否哟你直接或不是使用Core，你 使用它（ EntityManager 是 Session ）。所以，是的，如果你真的必须回归Core，那么很容易（对于那些仍然不在规范中的事物，比如Query By Example）。并且，不会，这不会导致任何问题（因为您实际上正在JPA中使用它或其子集）。

• 差异Hibernate 3.5 / JPA 2.0

The Hibernate EntityManager documentation states, that:

You may use a combination of all three together, annotations without JPA programming interfaces and lifecycle, or even pure native Hibernate Core, depending on the business and technical needs of your project. You can at all times fall back to Hibernate native APIs, or if required, even to native JDBC and SQL.

Code that uses the JPA API (EntityManager) is clearly more portable (even with occasional fallbacks to Hibernate Core).

But would I have any advantages when using purely Hibernate Core? I wonder, if the JPA 2 model really fits on top of Hibernate Core without any contradictions? IOW, is a fallback to Core always easy and without problems?

My main concern is this:

Maybe the differences are not only in the API, but also in the underlying semantics?! (e. g. different transaction/versioning/locking semantics that may conflict: Pessimistic locking is mentioned in the Core documentation, but not in the EntityManager documentation - so could I still use pessimistic locking by falling back to Core without causing problems? Things like that...)

解决方案

But would I have any advantages when using purely Hibernate Core?

If JPA 2.0 supports what you need, there is in my opinion no advantage at using Hibernate Core directly (and with JPA 2.0, the gap became more thin, making the need to fallback to Core the exception, not the rule, which is a very good thing).

I wonder, if the JPA 2 model really fits on top of Hibernate Core without any contradictions?

It does since JPA 1.0, the Hibernate developers created Hibernate3 with "JPA in mind" and adopted JPA semantics, defaults, etc in Hibernate3. You might want to listen to Gavin in this Tech Talk: Gavin King on Hibernate3 and EJB3:

In this tech talk King discusses how Hibernate3 builds upon and extends EJB3, addressing such topics as:

• New features of Hibernate3
• The relationship between Hibernate3 and the EJB3 container in JBoss
• What differentiates Hibernate3 from the EJB3 specification
• Hibernate's custom annotations available outside EJB
• The future of Hibernate

And according to my practical experience, the fact that Hibernate doesn't contradict with EJB 3 is true.

IOW, is a fallback to Core always easy and without problems?

Whether you use Core directly or not, you are using it (the EntityManager is a wrapper around the Session). So, yes, falling back to Core is easy if you really have to (for things that are still not in the spec like Query By Example, for example). And, no, this won't cause any problems (since you actually are using it, or a subset of it, in JPA).

Related questions

• Difference Hibernate 3.5 / JPA 2.0

这篇关于使用Hibernate EntityManager（与Hibernate Core）的任何缺点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！