java - indice - ¿Te gustan los criterios api de JPA 2.0? ¿Lo usas con marco?
ipa asma 2018 (4)
Estoy acostumbrado a trabajar con Criteria API en Hibernate, y solo observé cómo funcionan los Criterios en JPA 2.0.
Lo que más me gusta de los Criterios de Hibernate es la facilidad que tenemos para componer con los Criterios.
Los criterios de JPA me parecen bastante pesados, y no tan fluidos como los criterios de hibernación. Uno de los principales beneficios en comparación con Hibernate para mí parece ser el uso del metamodelo (clases Entity_.java), pero aún así es un poco pesado ya que tiene que mantener 2 clases o agregar un procesador de anotaciones (aunque es bastante fácil integrar con plugins de maven)
He leído un blog en SpringSource que permite reducir la complejidad de la composición con "JPA Predicates" y hacer un poco como con Criterions in Hibernate.
El proyecto Querydsl parece interesante.
http://blog.springsource.com/2011/04/26/advanced-spring-data-jpa-specifications-and-querydsl/
Solo me pregunto, para aquellos que usan JPA2, ¿está utilizando la API de criterios o es demasiado pesado para usted?
Para aquellos familiarizados con los Criterios de Hibernate y que ahora trabajan con los Criterios de JPA, ¿cuál es el enfoque que más le gusta y por qué?
¿Está considerando usar, o usar, un marco como Querydsl o Spring Especificaciones sobre JPA2 para construir sus predicados de consulta? ¿Crees que estos marcos son lo suficientemente maduros para ser adoptados?
No, no me gusta, debido a la falta de expresividad y fluidez en la API. Sí QueryDSL hace lo mismo en menos código, y más naturalmente. Por esa razón, hemos tomado la misma ruta para la propia API de consulta de JDO, comparándola con los criterios de JPA https://datanucleus.wordpress.com/2010/11/09/jdo-typesafe-vs-jpa-criteria/
Solo puedo dar una opinión sesgada, ya que soy el mantenedor de Querydsl, pero creo que tanto Querydsl como Spring Specification están lo suficientemente maduras. Ambos proporcionan una capa delgada sobre JPA 2, Querydsl proporciona un DSL fluido para la construcción de consultas y los patrones de datos de primavera para la construcción de DAO / Repository.
La expresividad de Querydsl es comparable a HQL / JPQL.
Aquí hay algunas consultas de JPA 2 Criteria y sus versiones de Querydsl: http://source.mysema.com/forum/mvnforum/viewthread_thread,49
Brindamos ciclos rápidos de corrección de errores y soporte receptivo en nuestros foros. El equipo de Querydsl coopera con Spring, DataNucleus y otras partes para mejorar el estado de las consultas de escritura segura en Java.
Uso intensivamente el generador de criterios JPA. Utilizo el metamodelo, variante de tipo seguro, pero esa no es la única opción. Si desea comparar JPA con otros marcos, no cuente el hecho de que necesita generar clases de metamodelo. Usted no, para la misma funcionalidad, solo para beneficios adicionales. Sin embargo, no volvería a ningún enfoque que no sea seguro para el tipo.
Cuando te acostumbras a él, es bastante simple de usar y aún es poderoso.
Un beneficio adicional: es estándar. Como en: varios expertos de diferentes organizaciones estuvieron de acuerdo. La calidad de la especificación es cierta y sigue evolucionando. Y obtiene múltiples implementaciones (en realidad, al menos dos de ellas se usan en los servidores de aplicaciones más populares). No entiendes eso si tomas un marco aleatorio, que puede o no ser la prueba del tiempo.
Algunos ejemplos de JPA2:
Root<Person> personRoot = query.from(Person.class);
Path firstNamePath = personRoot.get(Person_.firstName);
Predicate firstNamePredicate = criteriaBuilder.equal(firstNamePath, "Roger");
query.where(firstNamePredicate);
Podrías exprimir todo esto en una sola línea, pero la mayoría de las veces elijo no hacerlo para obtener un código claro al 100% y una declaración por línea.
Utilizo JPA2 en mis proyectos y siempre encontré que los criterios API estaban demasiado complicados, especialmente para crear declaraciones simples de selección con algunas condiciones.
Así que decidí seguir usando consultas JPQL. Tal vez la API de criterios tiene su fuerza con consultas más complejas (además de algunas otras ventajas).