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
Related answers
与恶龙缠斗过久,自身亦成为恶龙；凝视深渊过久,深渊将回以凝视…
