使用什么：JPQL或Criteria API？
我的Java应用程序正在使用JPA进行对象持久化。 业务领域非常简单（只有三个类是持久的，每个属性有3-5个）。 查询也很简单。 问题是我应该使用哪种方法：JPQL还是Criteria API？
我很确定这已经在这里覆盖了，但是我找不到现存的问题。 所以，这就是我对这个问题的看法：
- 我发现JPQL查询更易于编写/读取。
- 我发现Criteria API很适合构builddynamic查询。
基本上，你会发现在Hibernate中：Criteria vs. HQL 。
但是JPA 2.0 Criteria API和Hibernate Criteria API之间有一个主要的区别，值得一提：JPA 2.0 Criteria API是一个types安全的API ，因此提供了编译时间检查，代码完成，更好的重构支持等等。但是， 我没有发现这些好处超过了JPQL的易用性。
总结一下，除了dynamic查询（比如多条件search特性），我会倾向于JPQL。
相关问题
- Hibernate：标准与HQL
- JPA2 Criteria API更受欢迎的真实世界的例子是什么？
更多资源
- Hibernate查询102：Criteria API
我之前回答过类似的问题，为了社区的利益，我会在这里重新发表我的答案。 我将假设你正在使用一个应用程序服务器对我的答案下面。
Criteria API存在允许以防止SQL注入的types安全的方式构builddynamicSQL查询。 否则，您会将SQLstring连接在一起，这既容易出错又会带来安全风险：即SQL注入。 这将是唯一一次你想要使用Criteria API。
如果查询保持基本相同，但只需要接受不同的参数，则应使用带注释的@NamedQueries，这些更简单的预编译可在二级caching中caching，并可能在服务器启动期间进行validation。
这基本上是关于Criteria Queries和@NamedQueries的经验法则。 根据我的经验，您很less需要Criteria API，但是在需要这种罕见的时候它是存在的。
希望这可以帮助。
我想你也可以考虑一些其他新的框架，如：
查询Dsl
对象查询
鱼雷查询
这给你一个types安全和聪明的方式来build立查询，不是标准的，但我很确定下一个标准将基于这种技术之一。
如果你想保持标准忽略这一点。
再见
