是否有 Criteria API 和 NamedQuery 之间的决策启发/最佳做法/规则集？
到目前为止我的想法：
命名查询通常更具可读性。条件查询更灵活。
两者都是预编译的。我倾向于尽可能长时间地使用命名查询，然后改为标准。
但也许
使用标准API“灵活”查询的冲动是暗示设计不理想（即关注点分离）？
谢谢
答案 0 :(得分：34)
命名查询更优化（它们被解析/准备一次）。 Criteria查询是动态的（它们不是预编译的，尽管一些JPA提供程序，如EclipseLink维护标准准备缓存）。
我只会将标准用于动态查询。
答案 1 :(得分：10)
例如，当必须基于变量和多个搜索条件动态生成查询时，条件查询是一个不错的选择。
对于静态查询，JPQL更具可读性，我更喜欢使用它们而不是条件查询。你可能会失去一些安全感，但单元测试应该会让你更自信。
答案 2 :(得分：4)
另一个观点是虽然条件查询不是那么可读，但它是类型安全的，因此提供了编译时类型检查。如果在具有许多实体和许多查询的项目中更改数据库，那么在编译时查看由于更改而导致哪些查询出错是非常有用的。
另一方面，我不确定这比JPQL的简单性更有益
答案 3 :(得分：2)
我实际上经历了Hibernate（4.3.0-SNAPSHOT）源代码和EclipseLink（2.5.0-SNAPSHOT）源代码，并查看了每个代码中的JPA实现。
EclipseLink显然不是您描述的方式的线程安全。具体来说，它会尝试重复重新计算联接。
Hibernate的实现看起来对我来说是安全的。我不是100％肯定，但似乎确实如此。我会说，由于没有明确规定，未来不能保证这是真的。
但是，我会警告你，我不认为你会获得太多收益。从我所看到的，查询的大部分编译实际上是在＆＃34; createQuery＆＃34;阶段，所以你甚至不会获得很多缓存结果。
答案 4 :(得分：1)
JPA还提供了一种使用@NamedQuery和@NamedQueries注释构建静态查询（如命名查询）的方法。在可能的情况下，在JPA中优先考虑命名查询而不是动态查询是一种很好的做法。来自http://www.objectdb.com/java/jpa/query/api