使用方法：JPQL或Criteria API？ [关闭]

Posted 2021-03-26

我的Java应用程序使用JPA进行对象持久化。业务域非常简单（只有三个类是持久的，每个类有3-5个属性）。查询也很简单。问题是我应该使用哪种方法：JPQL或Criteria API？

答案

我很确定这已经在SO上面了，但我找不到现有的问题。所以，这是我对这个问题的看法：

• 我发现JPQL查询更容易编写/读取。
• 我发现Criteria API非常适合构建动态查询。

这基本上是你在Hibernate: Criteria vs. HQL找到的。

但是JPA 2.0 Criteria API和值得一提的Hibernate Criteria API之间存在一个主要区别：JPA 2.0 Criteria API是一个类型安全的API，因此可以提供编译时间检查，代码完成，更好的重构支持等。但是，我没有发现这些好处超过了JPQL的易用性。

总而言之，除了动态查询（例如，对于多标准搜索功能），我更青睐JPQL。

Related questions

• Hibernate: Criteria vs. HQL
• What are some of the real world example where JPA2 Criteria API is more preferable?

More resources

• Hibernate Querying 102 : Criteria API

另一答案

我之前回答过类似的问题，为了社区的利益，我会在这里重新发布我的答案。我将假设您正在使用Application Server，而不是我在下面的答案。

Criteria API用于允许以类型安全的方式构造动态SQL查询，以防止SQL注入。否则，您将SQL字符串连接在一起，这既容易出错又存在安全风险：即SQL注入。那是您唯一想要使用Criteria API的时间。

如果查询基本保持相同但只需要接受不同的参数，则应使用带注释的@NamedQueries，它更简单，预编译，可以缓存在二级缓存中，并可能在服务器启动期间进行验证。

这基本上是关于Criteria Queries与@NamedQueries的经验法则。根据我的经验，您很少需要Criteria API，但它很好，它存在于需要的极少数时间。

希望这可以帮助。

另一答案

我想你也可以考虑一些其他的新框架，如：

Query Dsl

Object Query

Torpedo Query

这为您提供了一种安全且智能的方式来构建查询，这不是标准的，但我确信下一个标准将基于这种技术之一。

如果你想保持标准，请忽略这一点。

再见