Java 使用什么：JPQL 或 Criteria API？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3858406/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What to use: JPQL or Criteria API?
提问by yegor256
My Java application is using JPA for object persistence. The business domain is very simple (just three classes are persistent, with 3-5 properties in each). Queries are simple as well. The question is which approach I should use: JPQL or Criteria API?
我的 Java 应用程序使用 JPA 进行对象持久化。业务域非常简单（只有三个类是持久的，每个类有 3-5 个属性）。查询也很简单。问题是我应该使用哪种方法：JPQL 还是 Criteria API？
采纳答案by Pascal Thivent
I'm pretty sure this has already been covered here on SO but I couldn't find the existing question. So, here is my point of view on the question:
我很确定这已经在 SO 上进行了介绍，但是我找不到现有的问题。所以，这是我对这个问题的看法：
- I find JPQL queries easier to write/read.
- I find the Criteria API nice for building dynamic queries.
- 我发现 JPQL 查询更容易写/读。
- 我发现 Criteria API 非常适合构建动态查询。
Which is basically what you'll find in Hibernate: Criteria vs. HQL.
这基本上就是你会在Hibernate: Criteria vs. HQL 中找到的内容。
But there is one major difference between the JPA 2.0 Criteria API and the Hibernate's Criteria API that is worth mentioning: the JPA 2.0 Criteria API is a typesafe APIand thus gives compile time checks, code completion, better refactoring support, etc. However, Idon't find that the benefits outweighs the ease of use of JPQL.
但是 JPA 2.0 Criteria API 和 Hibernate 的 Criteria API 之间有一个主要区别值得一提：JPA 2.0 Criteria API 是一种类型安全的 API，因此提供了编译时检查、代码完成、更好的重构支持等。但是，我不要发现好处超过了 JPQL 的易用性。
To sum up, I would favor JPQL, except for dynamic queries (e.g. for multi criteria search features).
总而言之，我更喜欢 JPQL，除了动态查询（例如，对于多条件搜索功能）。
Related questions
相关问题
- Hibernate: Criteria vs. HQL
- What are some of the real world example where JPA2 Criteria API is more preferable?
More resources
更多资源
回答by tglman
i think you can also consider some other new framework like:
我认为您还可以考虑其他一些新框架，例如：
this give you a type safe and smart way to build queries, are not standard, but i'm quite sure that the next standard will be based on one of this technology.
这为您提供了一种类型安全且智能的方式来构建查询，虽然不是标准的，但我很确定下一个标准将基于其中一项技术。
if you want remain on the standards ignore this.
如果您想保持标准，请忽略这一点。
bye
再见
回答by sagneta
I answered a similar question previously and I will re-post my answer here for the benefit of the community. I'm going to assume you are using an Application Server vis-a-vis my answer below.
我之前回答过类似的问题，为了社区的利益，我将在此处重新发布我的答案。我将假设您正在使用应用程序服务器，而不是我在下面的回答。
The Criteria API exists to allow for the construction of dynamic SQL queries in a type-safe manner that prevents SQL injection. Otherwise you would be concatenating SQL strings together which is both error prone and a security risk: i.e. SQL Injection. That would be the only time you would want to use the Criteria API.
Criteria API 的存在允许以防止 SQL 注入的类型安全方式构建动态 SQL 查询。否则，您会将 SQL 字符串连接在一起，这既容易出错又存在安全风险：即 SQL 注入。那将是您唯一想要使用 Criteria API 的时候。
If the query remains basically the same but need only accept different parameters you should use annotated @NamedQueries which are simpler, precompiled, can be cached within the secondary cache and possibly validated during server startup.
如果查询保持基本相同但只需要接受不同的参数，则应使用带注释的 @NamedQueries，它们更简单、预编译、可以缓存在二级缓存中，并可能在服务器启动期间进行验证。
That's basically the the rule of thumb concerning Criteria Queries versus @NamedQueries. In my experience rarely do you require the Criteria API but it is good that it exists for those rare times it is required.
这基本上是关于 Criteria Queries 与 @NamedQueries 的经验法则。根据我的经验，您很少需要 Criteria API，但它存在于那些极少数需要它的情况下是件好事。
Hope this helps.
希望这可以帮助。
