java 使用休眠 sessionFactory 还是 JPA entityManager？

Use hibernate sessionFactory or JPA entityManager?

提问by CorayThan

I'm working on a project that uses Hibernate 4.1, Spring 3.1, and JPA 2.0, and I want to verify that what I've gleaned from the internet is correct.

我正在开发一个使用 Hibernate 4.1、Spring 3.1 和 JPA 2.0 的项目，我想验证我从互联网上收集到的信息是否正确。

I'm trying to decide whether to use a JPA entityManager or the hibernate-specific sessionFactory.

我正在尝试决定是使用 JPA entityManager 还是特定于休眠的 sessionFactory。

At first I planned to use entityManager and full JPA specifications, so my project would be decoupled from Hibernate, and I could switch it out for something else, say EclipseLink, if the fancy took me or something convinced me later on.

起初我计划使用 entityManager 和完整的 JPA 规范，所以我的项目将与 Hibernate 分离，我可以将它切换到其他东西，比如 EclipseLink，如果我喜欢或后来说服了我。

However, it seems the entityManager has some very significant limitations.

然而，entityManager 似乎有一些非常重要的限制。

My questions:

我的问题：

The only reason I would want to use full JPA specifications and the entityManager is to be able to switch out Hibernate for a different JPA 2.0 compatible ORM relatively easily, right? Are there really no performance / functionality / ease of programming benefits to using the entityManager?

我想要使​​用完整的 JPA 规范和 entityManager 的唯一原因是能够相对容易地为不同的 JPA 2.0 兼容 ORM 切换 Hibernate，对吗？使用 entityManager 真的没有性能/功能/易于编程的好处吗？

Second, it seems like the hibernate sessionFactory has a lot of benefits over the entityManager. So far I've run into the issue that the entityManager can't perform a batch insert of a list of entities, which I've read the sessionFactory can. I've also read that the sessionFactory can return an auto-generated entity ID automatically, while with the entityManager you need to end the transaction / flush the persistence context to pull the newly generated id.

其次，似乎休眠 sessionFactory 比 entityManager 有很多好处。到目前为止，我遇到了 entityManager 无法批量插入实体列表的问题，我已经阅读了 sessionFactory 可以。我还读到 sessionFactory 可以自动返回一个自动生成的实体 ID，而使用 entityManager 您需要结束事务/刷新持久性上下文以提取新生成的 ID。

I liked the idea of my project being relatively decoupled from Hibernate, but I would much rather be able to write efficient database updates from the get-go. So I should switch over to my project being configured for hibernate and the sessionFactory, right?

我喜欢我的项目与 Hibernate 相对分离的想法，但我更愿意从一开始就编写高效的数据库更新。所以我应该切换到为休眠和 sessionFactory 配置的项目，对吗？

采纳答案by NoDataFound

I would stick to JPA2, like you would use Listrather than ArrayList: you favour the interface (or abstract) over the implementation. There are not much difference, apart from HQL knowing "more" stuff than JPQL or exotic feature. Also remember that JPA was made after Hibernate, with Hibernate being the "inspiration" behind JPA.

我会坚持 JPA2，就像你会使用List而不是ArrayList：你喜欢接口（或抽象）而不是实现。除了 HQL 比 JPQL 或外来特性知道“更多”的东西之外，没有太大区别。还要记住，JPA 是在 Hibernate 之后制作的，Hibernate 是 JPA 背后的“灵感”。

And for exotic feature: Hibernate Entity Manager wrap an Hibernate Session. If you really need them, you can cast the EntityManagerto the Hibernate interface (org.hibernate.jpa.HibernateEntityManager), and use that session. But I'd be lying to you if I say I tried it.

对于奇特的功能：Hibernate Entity Manager 包装了一个 Hibernate Session。如果您真的需要它们，您可以将EntityManager转换为 Hibernate 接口 ( org.hibernate.jpa.HibernateEntityManager)，并使用该会话。但如果我说我试过了，那我就是在骗你。

I also commented part of your question:

我还评论了您的部分问题：

The only reason I would want to use full JPA specifications and the entityManager is to be able to switch out Hibernate for a different JPA 2.0 compatible ORM relatively easily, right? Are there really no performance / functionality / ease of programming benefits to using the entityManager?

我想要使​​用完整的 JPA 规范和 entityManager 的唯一原因是能够相对容易地为不同的 JPA 2.0 兼容 ORM 切换 Hibernate，对吗？使用 entityManager 真的没有性能/功能/易于编程的好处吗？

Switching from Hibernate to EclipseLink does not mean you "only need to swap the jar". The mapping, and annotation parsing, is not the same and you'll encounter problems that will probably discourage you from switching.

从 Hibernate 切换到 EclipseLink 并不意味着您“只需要交换 jar”。映射和注释解析并不相同，您会遇到可能会阻止您切换的问题。

You can read my question herefor an example of a problem I encountered while using both (it was a maven project with a profile to switch JPA2.1 impl from EclipseLink to Hibernate). I dropped EclipseLink because I could not name the database object (or rather, specify the name of database object) like I wanted.

您可以在此处阅读我的问题，以获取我在使用两者时遇到的问题示例（这是一个带有配置文件的 Maven 项目，用于将 JPA2.1 impl 从 EclipseLink 切换到 Hibernate）。我放弃了 EclipseLink，因为我无法像我想要的那样命名数据库对象（或者更确切地说，指定数据库对象的名称）。

Second, it seems like the hibernate sessionFactory has a lot of benefits over the entityManager. So far I've run into the issue that the entityManager can't perform a batch insert of a list of entities, which I've read the sessionFactory can. I've also read that the sessionFactory can return an auto-generated entity ID automatically, while with the entityManager you need to end the transaction / flush the persistence context to pull the newly generated id.

其次，似乎休眠 sessionFactory 比 entityManager 有很多好处。到目前为止，我遇到了 entityManager 无法批量插入实体列表的问题，我已经阅读了 sessionFactory 可以。我还读到 sessionFactory 可以自动返回一个自动生成的实体 ID，而使用 entityManager 您需要结束事务/刷新持久性上下文以提取新生成的 ID。

This depends on how you generate your entity id. But think about it: you entity is not persisted until the persistence context need to persist it. This is the reason you don't have an id. Flushing it, aka sending an insert query with a generated id, is the only way to do it.

这取决于您如何生成实体 ID。但是想一想：在持久化上下文需要持久化它之前，你的实体不会被持久化。这就是你没有身的原因。刷新它，也就是发送一个带有生成的 id 的插入查询，是唯一的方法。

The same apply to session factories.

这同样适用于会话工厂。

You might however be able to access a sequence generator from Hibernate, but you can also do that in native SQL with EntityManager.

然而，您可能能够从 Hibernate 访问序列生成器，但您也可以在本机 SQL 中使用EntityManager.

I liked the idea of my project being relatively decoupled from Hibernate, but I would much rather be able to write efficient database updates from the get-go. So I should switch over to my project being configured for hibernate and the sessionFactory, right?

我喜欢我的项目与 Hibernate 相对分离的想法，但我更愿意从一开始就编写高效的数据库更新。所以我应该切换到为休眠和 sessionFactory 配置的项目，对吗？

You can take it as a troll against ORM, but for efficient database update, use plain JDBC (or Spring Jdbc Template). At least you'll know when data will be updated, and you'll be able to better optimize (batch update, etc).

您可以将其视为反对 ORM 的巨魔，但为了高效的数据库更新，请使用普通的 JDBC（或 Spring Jdbc 模板）。至少您会知道数据何时更新，并且您将能够更好地优化（批量更新等）。

回答by George Papatheodorou

JPA is an interface over Hibernate which is an interface over jdbc so the closer you are to jdbc the more control you get over your queries but further you go from object/relational persistence . Yes, Hibernate may have some tools that jpa may not provide at this moment (i.e hibernate spatial) Hibernate is fun and can use JPA annotations for mapping the domain model (if you go the annotations way over the .hbm files) . And the way the @Transactional annotation works in Spring it doesnt matter whether you use hibernate or jpa since you dont need session.open() ... session.beginTranscation ...session.close ...etc ... all this verbose Hibernate code is gone! There is great documentation on Hibernate and greate books as well. As for JPA I cant say that I found the umber book...

JPA 是基于 Hibernate 的接口，它是基于 jdbc 的接口，因此您离 jdbc 越近，您对查询的控制就越多，但离对象/关系持久性越远。是的，Hibernate 可能有一些 jpa 目前可能不提供的工具（即休眠空间） Hibernate 很有趣，并且可以使用 JPA 注释来映射域模型（如果您通过 .hbm 文件使用注释方式）。并且 @Transactional 注释在 Spring 中的工作方式无论您使用 hibernate 还是 jpa 都没有关系，因为您不需要 session.open() ... session.beginTranscation ...session.close ... etc ... 所有这些冗长Hibernate 代码不见了！也有关于 Hibernate 和伟大书籍的优秀文档。至于 JPA，我不能说我找到了 umber 书...