使用什么:JPQL或Criteria API?[关闭]


69

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

Answers:


79

我很确定这已经在此处讨论了,但是我找不到现有的问题。所以,这是我对这个问题的看法:

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

基本上可以在Hibernate中找到:Criteria vs. HQL

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

综上所述,除动态查询(例如,用于多条件搜索功能)外,我希望使用JPQL。

相关问题

更多资源


3
抱歉,恢复旧线程很抱歉,但是请不要JPQL过多避免。不是说使用JPQL是一种不好的做法,而是说如果可以使用Criteria完成某些工作,那么就应该在不使用JPQL的情况下进行。我只是在虚心地寻求您的更多说明,而不是质疑您对JPQL而不是标准的偏爱。
Shahzeb 2012年

5
@Shahzeb不,绝对不是。不要将标准API用于任何静态内容-例如,如果可以在编译时将查询编写为JPQL,则应使用JPQL。当然,不要以散落在代码中的字符串形式出现,应该避免这些字符串;但作为命名查询。某些IDE在启动时甚至在编辑时都会对其进行解析。
Hauke Ingmar Schmidt,2012年

9

我之前回答了类似的问题,为了社区的利益,我将在这里重新发布我的答案。我将假设您正在使用我下面的答案所对应的Application Server。

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

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

这基本上是关于Criteria Queries vs的经验法则@NamedQueries。以我的经验,您很少需要Criteria API,但在极少数情况下需要它,这很好。

希望这可以帮助。


串联常量字符串以创建JPQL查询没有安全风险。这正是CriteriaBuilder所做的。那么,除了使代码完全不可读和难以理解之外,CriteriaBuilder的优点是什么?
bebbo

-2

我认为您也可以考虑其他一些新框架,例如:

查询Dsl

对象查询

鱼雷查询

这为您提供了一种构建查询的安全而聪明的方式,这不是标准的,但是我很确定下一个标准将基于该技术之一。

如果要保留在标准上,请忽略此。

再见


这与是否是更好的问题无关,应该将其添加为原始问题的注释
Adrian Legaspi
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.