使用Hibernate EntityManager(与Hibernate Core相比)有什么缺点吗?

但是当我使用纯Hibernate内核时有什么好处吗?

如果jpa2.0支持您所需要的,那么在我看来,直接使用Hibernate Core没有任何优势(而在jpa2.0中,差距变得越来越小,使得需要回退到Core成为例外,而不是规则,这是一件非常好的事情)。

我想知道,jpa2模型是否真的适合Hibernate内核之上而没有任何矛盾?

从jpa1.0开始,Hibernate开发人员创建Hibernate3时就考虑到了“JPA”,并在Hibernate3中采用了JPA语义、默认值等。你可能想听听加文的话 Tech Talk: Gavin King on Hibernate3 and EJB3 :

在这篇科技演讲中,金讨论了 EJB3型 ,涉及以下主题:

• Hibernate3与JBoss中EJB3容器的关系
• Hibernate3与EJB3规范的区别是什么
• 在EJB外部提供Hibernate的自定义注释
• 冬眠的未来

根据我的实践经验,Hibernate与ejb3并不矛盾这一事实是正确的。

无论您是否直接使用核心,您 是 使用它(the EntityManager 是一个包裹 Session

相关问题

• Difference Hibernate 3.5 / JPA 2.0

取决于项目的业务和技术需求

但是当我使用纯Hibernate内核时有什么好处吗?

不要忘记Hibernate注释和Hibernate EntityManager都构建在Hibernate核心之上。 再来一层

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

JDBC >> Hibernate core >> Hibernate Annotations

...

JDBC >> Hibernate core >> Hibernate EntityManager

• 包装可嵌入

等等。。。

不要忘记JPA EntityManager允许您使用 getDelegate 方法,如果您需要JPA不提供的特性。

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

我对使用第二层访问Hibernate核心功能并不感兴趣。就我而言,持久层的可移植性是 完全不发行 .

与HibernateAPI相比,JPAAPI几乎没有什么真正的优势——我看到有人使用JPAAPI命名的查询(这里的条件可能更清晰&更好),而且JPA注释的设计也更好一些。

除此之外,JPA只是一个增加复杂性的层;潜在的管理费用——毫无益处。在这种情况下,正确的决定是反对使用它。

数据库的可移植性非常真实。我使用的自定义分配器(生成器)是完全可移植的,而且性能更高;比设计错误的休眠模式更简单。

这种方法在多个主要商业、政府和;遗留数据库重新设计项目。简言之——关注什么是重要的——一个API在一个API之上,不是吗。

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