JPA2 Criteria API更受欢迎的真实世界的例子是什么？ [英] What are some of the real world example where JPA2 Criteria API is more preferable?

问题描述

我已经看过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< Person> c = qb.createQuery（Person.class）; 
 Root< Person> p = c.from（Person.class）; 
谓词条件= qb.gt（p.get（Person_.age），20）; 
 c.where（condition）; 
 TypedQuery< Person> q = em.createQuery（c）; 
列表< Person> result = q.getResultList（）; 
  

在上面的代码片段中，以下内容会引发编译错误：

 谓词条件= qb.gt（p.get（Person_.age，xyz））; 
  

如果您想知道， Person _ 是对应于原始 Person 实体类（由注释处理器生成）的静态，实例化，规范元模型类。它为基于运行时反射的方法提供了强类型的替代方案：

  Field field = Person.class.getField（age） ; 
  

优点：

• 输入安全性，编译时间验证！
  
  
  
  
  • 禁止构造语法不正确的查询。
  
  
  • 重构后可能引发编译错误。 li>
    
  • 提供开箱即用的支持以自动完成
  
  


• 更适合动态查询。 li>
  

缺点：

• li>
  
• 可读性较差。

我觉得一般情况下JPQL更舒适，但Criteria API是与JPQL（以及Hibernate Criteria API）的主要区别。

另见

• 使用Criteria API和Metamodel API创建基本类型 - 安全查询


• 动态，JPA 2.0中的类型安全查询


• 比较JPQL，Criteria基于字符串和类型安全查询


• JPA的类型安全标准查询API
>

相关答案

• hibernate查询语言或使用条件


• Hibernate：Criteria vs. HQL

I have taken a look at JPA 2.0 Criteria API, but I found it to be too cumbersome unlike Hibernate Criteria. Is there any good reason to use JPA 2.0 Criteria API rather than using JPA-QL? Thanks for your advise.

解决方案

Like the Hibernate Criteria API, the JPA 2.0 Criteria API is especially nice to build queries dynamically, to handle cases where the query structure varies depending upon runtime conditions.

But there is more. While being more verbose than Hibernate's Criteria API, the JPA Criteria API allows to build typesafe queries (if you use the Metamodel API). Below an example:

EntityManager em = ...
QueryBuilder qb = em.getQueryBuilder();
CriteriaQuery<Person> c = qb.createQuery(Person.class);
Root<Person> p = c.from(Person.class);
Predicate condition = qb.gt(p.get(Person_.age), 20);
c.where(condition);
TypedQuery<Person> q = em.createQuery(c); 
List<Person> result = q.getResultList();

In the above snippet, the following would raise a compilation error for example:

Predicate condition = qb.gt(p.get(Person_.age, "xyz"));

In case you wonder, Person_ is the static, instantiated, canonical metamodel class corresponding to the original Person entity class (generated by an annotation processor). It provides a strongly typed alternative to a runtime reflection based approach:

Field field = Person.class.getField("age");

Pros:

• Type safety, compile time verification!
  • Prohibits the construction of queries that are syntactically incorrect.
  • Can raise a compilation error after a refactoring.
  • Provides out of the box support for auto-completion
• Better suited for dynamic queries.

Cons:

• More verbose.
• Less readable.

I feel in general more comfortable with JPQL but the type safety of the Criteria API is a major difference with JPQL (and also the Hibernate Criteria API).

See also

• Using the Criteria API and Metamodel API to Create Basic Type-Safe Queries
• Dynamic, typesafe queries in JPA 2.0
• Comparing JPQL, Criteria string-based and typesafe queries
• A typesafe criteria query API for JPA

Related answers

• Dynamic JPA 2.0 query using Criteria API
• hibernate query language or using criteria
• Hibernate: Criteria vs. HQL

这篇关于JPA2 Criteria API更受欢迎的真实世界的例子是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！