java - criteriaquery where
¿Cuáles son algunos de los ejemplos del mundo real donde JPA2 Criteria API es más preferible? (4)
He echado un vistazo a la API de criterios de JPA 2.0, pero me pareció demasiado engorroso a diferencia de los criterios de hibernación. ¿Hay alguna buena razón para usar JPA 2.0 Criteria API en lugar de usar JPA-QL? Gracias por tu consejo.
Al igual que la API de criterios de hibernación, la API de criterios de JPA 2.0 es especialmente buena para crear consultas dinámicamente , para manejar casos en que la estructura de consultas varía según las condiciones de tiempo de ejecución.
Pero hay más. Aunque es más detallado que la API de criterios de Hibernate, la API de criterios de JPA permite crear consultas seguras para los tipos (si utiliza la API de Metamodel). A continuación un ejemplo:
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();
En el fragmento de código anterior, lo siguiente generaría un error de compilación, por ejemplo:
Predicate condition = qb.gt(p.get(Person_.age, "xyz"));
En caso de que se pregunte, Person_ es la clase de metamodelo canónica estática, instanciada, correspondiente a la clase de entidad Person original (generada por un procesador de anotaciones). Proporciona una alternativa fuertemente tipada a un enfoque basado en la reflexión en tiempo de ejecución:
Field field = Person.class.getField("age");
Pros:
- Escriba seguridad, compilación tiempo de verificación!
- Prohíbe la construcción de consultas que sean sintácticamente incorrectas.
- Puede provocar un error de compilación después de una refactorización.
- Proporciona soporte inmediato para el autocompletado
- Más adecuado para consultas dinámicas.
Contras:
- Más detallado.
- Menos legible.
En general, me siento más cómodo con JPQL, pero el tipo de seguridad de la API de criterios es una gran diferencia con JPQL (y también la API de criterios de hibernación).
Ver también
- Uso de la API de criterios y la API de metamodelo para crear consultas básicas de seguridad de tipos
- Consultas dinámicas y seguras en JPA 2.0
- Comparando JPQL, criterios basados en cadenas de caracteres y consultas de tipos seguros
- Una API de consulta de criterios para JPA
Respuestas relacionadas
JPA 2.0 Criteria API es la API basada en objetos para crear consultas. Creo que puede desempeñar un buen trabajo cuando tiene una consulta dinámica que puede ser más legible de la siguiente manera
cq.select(...)
.where(...)
.orderBy(...)
.groupBy(...);
Pero al usar la consulta estática, prefiera usar un archivo externo, mantenible y legible .
<entity-mappings>
...
<named-query name="ORDER">
<query>
<![CDATA[
from
Order
]]>
</query>
</named-query>
<named-query name="ORDER_WITH_LINE_ITEM">
<query>
<![CDATA[
from
Order o
inner join fetch
o.lineItemList
]]>
</query>
</named-query>
...
</entity-mappings>
Si tiene una aplicación modular, use un archivo xml para cada módulo de la siguiente manera:
br
com
ar
moduleA
model
repository
moduleA.xml
moduleB
model
repository
moduleB.xml
moduleC
model
repository
moduleC.xml
Entonces usted define su elemento mappinf-file
<mapping-file>br/com/ar/moduleA/model/repository/moduleA.xml</mapping-file>
<mapping-file>br/com/ar/moduleB/model/repository/moduleB.xml</mapping-file>
<mapping-file>br/com/ar/moduleC/model/repository/moduleC.xml</mapping-file>
Los criterios de JPA 2 se pueden usar de forma estática si genera el metamodelo de la entidad. Es más detallado que JPQL, pero está tipificado estáticamente y admite la construcción dinámica de consultas directamente.
Los beneficios de un lenguaje de consulta de tipo estático es que puede detectar más errores en el momento de la compilación y también se pueden usar funciones IDE como autocompletar.
Para mí, el ejemplo del mundo real en el que brilla JPA2 es cuando se necesita crear una consulta basada en la entrada de un usuario. No estoy hablando de un simple donde con un solo parámetro. Me refiero a cuando ha realizado una opción de búsqueda avanzada en su aplicación. Una que requiere uniones cuando se llena un determinado parámetro. No tiene que concatenar su HQL o SQL para incluir un gran conjunto de parámetros, combinaciones y funciones adicionales. SQL personalizado requiere muchas pruebas para demostrar que funciona. Agregar opciones de búsqueda adicionales a HQL y SQL requiere una gran cantidad de trabajo, mientras que esto podría ser más simple en JPA.