java JPA 命名查询与标准 API？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/7334064/
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
JPA Named Queries vs Criteria API?
提问by kostja
Is there a heuristic/best practice/ruleset for a decision between the Criteria APIand NamedQuery?
在Criteria API和NamedQuery之间做出决定是否有启发式/最佳实践/规则集？
My thoughts so far :
Named queries are generally more readable. Criteria queries are more flexible.
Both are precompiled. I tend to rely on using named queries as long as possible, then changing to criteria.
But maybe
the urge to "flexify" the query by using the criteria API is a hint to suboptimal design (i.e. separation of concerns)?
到目前为止我的想法：
命名查询通常更具可读性。条件查询更加灵活。
两者都是预编译的。我倾向于尽可能长时间地使用命名查询，然后更改为标准。
但也许通过使用标准 API 来“灵活化”查询的冲动是对次优设计（即关注点分离）的暗示？
Thank you
谢谢
回答by James
Named queries are more optimal (they are parsed/prepared once). Criteria queries are dynamic, (they are not precompiled, although some JPA providers such as EclipseLink maintain a criteria prepare cache).
命名查询更优化（它们被解析/准备一次）。Criteria 查询是动态的（它们不是预编译的，尽管一些 JPA 提供程序如 EclipseLink 维护了一个标准准备缓存）。
I would use criteria only for dynamic queries.
我只会将标准用于动态查询。
回答by JB Nizet
Criteria queries are a good choice when a query must be generated dynamically, based of variable and multiple search criteria, for example.
例如，当必须根据变量和多个搜索条件动态生成查询时，条件查询是一个不错的选择。
For static queries, JPQL is much more readable, and I prefer using them than criteria queries. You could lose some safety, but the unit tests should make you more confident.
对于静态查询，JPQL 更具可读性，我更喜欢使用它们而不是标准查询。您可能会失去一些安全性，但单元测试应该让您更有信心。
回答by illEatYourPuppies
Another viewpoint is that although criteria query is not so readable, it is typesafe, therefore provides you compile time type checking. If you change the database in projects where there are many entities and many queries, it is really helpful to see at compile time what queries went wrong because of the change.
另一种观点是，虽然标准查询不太可读，但它是类型安全的，因此为您提供编译时类型检查。如果您在有许多实体和许多查询的项目中更改数据库，在编译时查看哪些查询因更改而出错非常有帮助。
On the other hand, I'm not sure that is more beneficial than the simpleness of JPQL
另一方面，我不确定这是否比 JPQL 的简单性更有益
回答by Yinzara
I actually went through the Hibernate (4.3.0-SNAPSHOT) source and the EclipseLink (2.5.0-SNAPSHOT) source and looked through the JPA implementation in each.
我实际上浏览了 Hibernate (4.3.0-SNAPSHOT) 源和 EclipseLink (2.5.0-SNAPSHOT) 源，并查看了每个源中的 JPA 实现。
EclipseLink is clearly not thread safe in the manner you describe. Specifically it tries to recalculate joins repeatedly.
EclipseLink 显然不是您描述的线程安全的方式。具体来说，它会尝试反复重新计算连接。
Hibernate's implementation looks thread safe to me. I'm not 100% sure, but it does seem to be. I would say that this is not guaranteed to be true in the future since it isn't specified.
Hibernate 的实现对我来说看起来是线程安全的。我不是 100% 确定，但似乎确实如此。我会说这在未来不能保证是真的，因为它没有被指定。
However, I will warn you, I don't think you're going to gain much. From what I'm looking at, much of the compilation of the query is actually done during the "createQuery" phase so you wouldn't even gain much caching the results.
但是，我会警告你，我不认为你会得到太多。从我所看到的，查询的大部分编译实际上是在“createQuery”阶段完成的，因此您甚至不会获得太多缓存结果。
回答by José Roberto Ramírez Aguilar
JPA also provides a way for building static queries, as named queries, using the @NamedQuery and @NamedQueries annotations. It is considered to be a good practice in JPA to prefer named queries over dynamic queries when possible. From http://www.objectdb.com/java/jpa/query/api
JPA 还提供了一种使用@NamedQuery 和@NamedQueries 注释构建静态查询的方法，如命名查询。在 JPA 中，在可能的情况下优先选择命名查询而不是动态查询被认为是一种很好的做法。来自http://www.objectdb.com/java/jpa/query/api
