Solución:
En general, prefiero las consultas de criterios para consultas dinámicas. Por ejemplo, es mucho más fácil agregar algunos pedidos de forma dinámica o dejar algunas partes (por ejemplo, restricciones) en función de algún parámetro.
Por otro lado, estoy usando HQL para consultas estáticas y complejas, porque es mucho más fácil de entender / leer HQL. Además, creo que HQL es un poco más potente, por ejemplo, para diferentes tipos de combinación.
Hay una diferencia en términos de rendimiento entre HQL y criteriaQuery, cada vez que dispara una consulta usando criteriaQuery, crea un nuevo alias para el nombre de la tabla que no se refleja en la última caché consultada para ninguna base de datos. Esto conduce a una sobrecarga de compilar el SQL generado, lo que lleva más tiempo para ejecutarse.
Respecto a las estrategias de búsqueda [http://www.hibernate.org/315.html]
- Criteria respeta la configuración de pereza en sus asignaciones y garantiza que se cargue lo que desea cargar. Esto significa que una consulta Criteria puede dar como resultado varias sentencias SELECT inmediatas de SQL para obtener el subgrafo con todas las asociaciones y colecciones mapeadas no diferidas. Si desea cambiar el “cómo” e incluso el “qué”, use setFetchMode () para habilitar o deshabilitar la búsqueda de combinaciones externas para una colección o asociación en particular. Las consultas de criterios también respetan completamente la estrategia de búsqueda (unirse vs seleccionar vs subseleccionar).
- HQL respeta la configuración de pereza en sus asignaciones y garantiza que se cargue lo que desea cargar. Esto significa que una consulta HQL puede dar como resultado varias sentencias SELECT inmediatas de SQL para obtener el subgrafo con todas las asociaciones y colecciones mapeadas no diferidas. Si desea cambiar el “cómo” e incluso el “qué”, use LEFT JOIN FETCH para habilitar la búsqueda de uniones externas para una colección en particular o asociación de muchos a uno o uno a uno que admite valores NULL, o JOIN FETCH para habilitar búsqueda de combinación interna para una asociación de varios a uno o uno a uno que no acepta valores NULL. Las consultas HQL no respetan ninguna fetch = “join” definida en el documento de mapeo.
Criteria es una API orientada a objetos, mientras que HQL significa concatenación de cadenas. Eso significa que se aplican todos los beneficios de la orientación a objetos:
- En igualdad de condiciones, la versión OO es algo menos propensa a errores. Cualquier cadena antigua podría agregarse a la consulta HQL, mientras que solo los objetos Criteria válidos pueden convertirse en un árbol de Criterios. Efectivamente, las clases de Criterios están más restringidas.
- Con la función de autocompletar, el OO es más visible (y por lo tanto más fácil de usar, al menos para mí). No es necesario que recuerde qué partes de la consulta van a dónde; el IDE puede ayudarte
- Tampoco es necesario recordar los detalles de la sintaxis (como qué símbolos van a dónde). Todo lo que necesita saber es cómo llamar a métodos y crear objetos.
Dado que HQL es muy parecido a SQL (que la mayoría de los desarrolladores ya conocen muy bien), estos argumentos de “no es necesario recordar” no tienen tanto peso. Si HQL fuera más diferente, entonces esto sería más importante.