使用方法:JPQL或Criteria API?

时间:2010-10-04 19:22:55

标签: java jpa jpa-2.0 jpql criteria-api

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

3 个答案:

答案 0 :(得分:74)

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

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

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

但JPA 2.0 Criteria API和值得一提的Hibernate Criteria API之间存在一个主要区别:JPA 2.0 Criteria API是 typesafe API ,因此可以进行编译时检查,代码完成,更好的重构支持等 但是, I 并没有发现这些好处超过了JPQL的易用性。

总而言之,除了动态查询(例如多标准搜索功能)之外,我更青睐JPQL。

相关问题

更多资源

答案 1 :(得分:4)

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

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

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

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

希望这有帮助。

答案 2 :(得分:-3)

我认为您还可以考虑其他一些新框架:

Query Dsl

Object Query

Torpedo Query

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

如果你想留在标准上,请忽略这一点。

再见