JPA2 Criteria API更优选的一些现实世界示例是什么？
我已经看了JPA 2.0 Criteria API，但我发现它与Hibernate Criteria不同，太麻烦了。 是否有充分的理由使用JPA 2.0 Criteria API而不是使用JPA-QL？ 感谢您的意见。
与Hibernate Criteria API一样，JPA 2.0 Criteria API特别适合动态构建查询，以处理查询结构因运行时条件而异的情况。
但还有更多。 虽然比Hibernate的Criteria API更冗长，但JPA Criteria API允许构建类型安全查询（如果您使用Metamodel API）。 下面是一个例子：
EntityManager em = ... QueryBuilder qb = em.getQueryBuilder(); CriteriaQuery c = qb.createQuery(Person.class); Root p = c.from(Person.class); Predicate condition = qb.gt(p.get(Person_.age), 20); c.where(condition); TypedQuery q = em.createQuery(c); List result = q.getResultList(); 在上面的代码片段中，以下内容会引发编译错误，例如：
Predicate condition = qb.gt(p.get(Person_.age, "xyz"));
如果您想知道， Person_是与原始Person实体类（由注释处理器生成）对应的静态，实例化，规范元模型类 。 它提供了基于运行时reflection的方法的强类型替代方法：
Field field = Person.class.getField("age");
优点：
- 类型安全，编译时validation！
- 禁止构造语法不正确的查询。
- 重构后可能引发编译错误。
- 提供开箱即用的自动完成支持
- 更适合动态查询。
缺点：
- 更冗长。
- 不太可读。
我觉得JPQL一般都比较舒服，但Criteria API的类型安全性与JPQL（以及Hibernate Criteria API）有很大的不同。
也可以看看
- 使用Criteria API和Metamodel API创建基本类型安全查询
- JPA 2.0中的动态，类型安全查询
- 比较JPQL，Criteria基于字符串和类型安全查询
- JPA的类型安全标准查询API
相关答案
- 使用Criteria API进行动态JPA 2.0查询
- hibernate查询语言或使用标准
- Hibernate：Criteria vs. HQL
JPA 2.0 Criteria API是用于构建查询的基于对象的API。 我认为当你有一个动态查询时它可以发挥得很好，它可以变得更具可读性 ，如下所示
cq.select(...) .where(...) .orderBy(...) .groupBy(...);
但是当使用静态查询时更喜欢使用外部化，可维护和可读的文件
... ...
如果您有模块化应用程序，请为每个模块使用一个xml文件，如下所示
br com ar moduleA model repository moduleA.xml moduleB model repository moduleB.xml moduleC model repository moduleC.xml
然后定义mappinf-file元素
br/com/ar/moduleA/model/repository/moduleA.xml br/com/ar/moduleB/model/repository/moduleB.xml br/com/ar/moduleC/model/repository/moduleC.xml
如果生成实体元模型，JPA 2 Criteria可以以静态类型forms使用。 它比JPQL更冗长，但是是静态类型的并且直接支持动态查询构造。
静态类型查询语言的好处是可以在编译时捕获更多错误，也可以使用自动完成等IDEfunction。
对我来说，当你需要根据用户的输入创建一个查询时，JPA2发光的真实世界的例子。 我不是在谈论一个非常简单的参数。 我的意思是你在应用程序中创建了一个高级搜索选项。 在填充某个参数时需要连接的一个。 你不需要连接你的HQL或SQL来包含大量参数，额外的连接和函数。 自定义SQL需要大量测试才能certificate它有效。 为HQL和SQL添加额外的搜索选项需要大量的返工，而在JPA中这可能更简单。