Qué uso: JPQL o los criterios del API? [cerrado]

Question

Mi aplicación Java está utilizando JPA para la persistencia de objetos. El dominio de negocio es muy simple (sólo tres clases son persistentes, con 3-5 propiedades de cada uno). Las consultas son simples también. La pregunta es cuál es el enfoque que debe utilizar:? JPQL o API Criterios

Answer 1

Estoy bastante seguro de que esto ya ha sido cubierto aquí en SO, pero no pude encontrar la pregunta existente. Así pues, aquí es mi punto de vista sobre la cuestión:

• Encuentro JPQL consulta más fácil de escritura / lectura.
• Me parece que el buen API Criterios para la construcción de consultas dinámicas.

que es básicamente lo que encontrará en Hibernate: Criterios vs HQL .

Pero hay una diferencia importante entre la API JPA 2.0 Criterios y API Criterios de la hibernación que vale la pena mencionar: la API JPA 2.0 Criterios es un typesafe API y por lo tanto da cheques tiempo de compilación, la finalización de código , refactorización mejor soporte, etc. Sin embargo, I no encuentran que los beneficios es mayor que la facilidad de uso de JPQL.

Para resumir, favorecería JPQL, a excepción de las consultas dinámicas (por ejemplo, los criterios de múltiples funciones de búsqueda).

preguntas relacionadas

• Hibernate: Criterios vs. HQL
• ¿Cuáles son algunos de los ejemplo del mundo real, donde es más preferible API JPA2 Criterios?

Más recursos

• Hibernate Consulta 102: Criterios API

Answer 2

Me respondió una pregunta similar con anterioridad y que se volverá a publicar mi respuesta aquí en beneficio de la comunidad. Voy a asumir que usted está utilizando un servidor de aplicaciones de vis-a-vis mi respuesta a continuación.

Existe la API Criterios para permitir la construcción de consultas SQL dinámico de una manera de tipo seguro de que la inyección previene SQL. De lo contrario, estaría junto concatenando cadenas SQL, que es a la vez propenso a errores y un riesgo de seguridad: es decir, la inyección de SQL. Esa sería la única vez que se desea utilizar la API Criteria.

Si la consulta sigue siendo básicamente el mismo, pero sólo es necesario aceptar diferentes parámetros que debe utilizar @NamedQueries anotados, que son más simples, precompilado, pueden almacenar en caché en el caché secundario y posiblemente validados durante el inicio del servidor.

Eso es básicamente el de la regla de oro en relación con consultas de criterios frente a @NamedQueries. En mi experiencia rara vez es lo que necesita la API Criterios pero es bueno que existe para aquellas raras ocasiones en que se requiera.

Espero que esto ayude.

Answer 3

creo que también se puede considerar algún otro nuevo marco como:

consulta DSL

de objetos de consulta

Torpedo de consulta

Esto le da una caja fuerte tipo y la forma inteligente de consultas de construcción, no son estándar, pero estoy seguro de que el próximo estándar se basa en una de esta tecnología.

si desea permanecer en las normas ignorar esto.

bye