JPA命名查询与条件API？

Question

在标准API 和 NamedQuery 之间进行决策时是否有启发式/最佳实践/规则集？

到目前为止我的想法：
命名查询通常更具可读性。条件查询更加灵活。
两者都是预编译的。我倾向于尽可能长时间地使用命名查询，然后更改为条件。

但也许 通过使用条件API“灵活化”查询的冲动是否暗示了欠佳的设计（即关注点分离）？

谢谢

Answer 1

命名查询更理想（它们被解析/准备一次）。条件查询是动态的（尽管某些JPA提供程序（例如EclipseLink维护条件准备高速缓存），它们并未预先编译）。

我只会将条件用于动态查询。

Answer 2

当必须基于变量和多个搜索条件动态生成查询时，条件查询是一个不错的选择。

对于静态查询，JPQL更具可读性，与标准查询相比，我更喜欢使用它们。您可能会失去一些安全性，但是单元测试应该使您更加自信。

Answer 3

另一个观点是，尽管条件查询不那么可读，但是它是类型安全的，因此可以为您提供编译时类型检查。如果您在存在许多实体和许多查询的项目中更改数据库，那么在编译时查看由于更改而导致查询出错的问题确实很有帮助。

另一方面，我不确定这是否比JPQL的简单性更有益

Answer 4

我实际上遍历了Hibernate（4.3.0-SNAPSHOT）源和EclipseLink（2.5.0-SNAPSHOT）源，并逐一研究了JPA实现。

EclipseLink显然不是您所描述的方式线程安全。具体来说，它会尝试重新计算联接。

Hibernate的实现对我而言似乎是线程安全的。我不确定100％，但是确实如此。我会说，由于未指定，因此不能保证将来会是真的。

但是，我会警告您，我认为您不会收获很多。根据我的观察，查询的大部分编译实际上是在“ createQuery”阶段完成的，因此您甚至不会获得太多的缓存结果。

Answer 5

JPA还提供了一种使用@NamedQuery和@NamedQueries批注构建静态查询（如命名查询）的方法。在JPA中，在可能的情况下，优先选择命名查询而不是动态查询，这是一种好习惯。来自 http://www.objectdb.com/java/jpa/query/api