JPA Nombrado Consultas vs Criterios API?

¿Existe una heurística/mejores prácticas/conjunto de reglas para una decisión entre API de criterios y NamedQuery?JPA Nombrado Consultas vs Criterios API?

Mis pensamientos hasta el momento:
Las consultas con nombre son generalmente más legibles. Las consultas de criterios son más flexibles.
Ambos están precompilados. Tiendo a confiar en el uso de consultas con nombre el mayor tiempo posible, y luego a los criterios.

Pero tal vez el impulso de "flexibilizar" la consulta mediante el uso de la API de criterios es una pista para el diseño subóptimo (es decir, la separación de las preocupaciones)?

Gracias

Fuente

2011-09-07 kostja

Las consultas con nombre son más óptimas (se analizan/preparan una vez). Las consultas de criterios son dinámicas (no están precompiladas, aunque algunos proveedores de JPA como EclipseLink mantienen un caché de preparación de criterios).

Utilizaría criterios solo para consultas dinámicas.

Fuente

2011-09-07 13:17:12 James

Estoy de acuerdo. ¡Buena respuesta! – Robin

Me gusta usar solo Criteria. Combina la API de Criteria con un metamodelo de la entidad y puedes abandonar completamente el uso de String y producir un código fuerte, para un geek de Java que es realmente divertido. Sin embargo, encontré la prueba [this] (http://milestonenext.blogspot.se/2013/02/jpql-vs-criteria.html) que en realidad muestra que los Criterios tienen un rendimiento incluso peor que el de JPQL. –

Técnicamente, esa prueba de rendimiento no utilizó el Metamodelo generado que es la mejor parte sobre la API de criterios de JPA. Al principio tuve una gran dificultad al cambiar de Hibernate Criteria a JPA, pero ahora realmente prefiero el JPA. – Yinzara

Criterios consultas son una buena opción cuando una consulta se debe generar de forma dinámica, en función de criterios de búsqueda y múltiples variables, por ejemplo.

Para las consultas estáticas, JPQL es mucho más legible, y prefiero usarlas que las consultas de criterios. Podrías perder algo de seguridad, pero las pruebas de la unidad deberían darte más confianza.

Fuente

2011-09-07 12:47:02

Otro punto de vista es que, aunque la consulta de criterios no es tan legible, es segura, por lo tanto, le proporciona la verificación del tipo de tiempo de compilación. Si cambia la base de datos en proyectos donde hay muchas entidades y muchas consultas, es realmente útil ver en tiempo de compilación qué consultas fallaron debido al cambio.

Por otro lado, no estoy seguro de que es más beneficioso que la sencillez de JPQL

Fuente

2012-07-31 08:13:09 illEatYourPuppies

De hecho, me fui a través de la fuente de Hibernate (4.3.0-SNAPSHOT) y el EclipseLink (2.5.0-SNAPSHOT) fuente y revisó la implementación de JPA en cada uno.

EclipseLink claramente no es seguro para subprocesos de la manera que usted describe. Específicamente, intenta volver a calcular uniones repetidamente.

La implementación de Hibernate me parece segura para hilos. No estoy 100% seguro, pero parece ser así. Diría que no se garantiza que esto sea cierto en el futuro ya que no está especificado.

Sin embargo, te lo advertiré, no creo que ganes mucho. Según lo que estoy viendo, gran parte de la compilación de la consulta se realiza en realidad durante la fase "createQuery", por lo que ni siquiera obtendría mucho almacenamiento en caché de los resultados.

Fuente

2014-03-16 03:37:37 Yinzara

JPA también proporciona una forma de generar consultas estáticas, como consultas con nombre, utilizando las anotaciones @NamedQuery y @NamedQueries. Se considera que es una buena práctica en JPA preferir las consultas con nombre sobre las consultas dinámicas cuando sea posible. De http://www.objectdb.com/java/jpa/query/api

Fuente

2014-06-06 16:36:52

JPA Nombrado Consultas vs Criterios API?

Respuesta

Cuestiones relacionadas