java - namedquery - jpa ejemplos
¿Por qué utilizar JPA en lugar de escribir directamente una consulta SQL en un archivo Java(es decir, directamente en JDBC)? (6)
¿Por qué utilizar JPA en lugar de escribir directamente una consulta SQL en un archivo Java (es decir, directamente en JDBC)?
Ciertos proyectos requieren que los ingenieros se centren más en el modelo de objetos que en las consultas SQL reales utilizadas para acceder a los almacenes de datos. La pregunta realmente puede ser interpretada como
¿Por qué debería uno usar un marco ORM?
que puede tener diferentes respuestas en diferentes contextos.
La mayoría de los proyectos pueden beneficiarse de tener un modelo de dominio, siendo la persistencia una segunda preocupación. Con JPA (implementaciones) o la mayoría de las demás estructuras ORM, es posible tener todas las entidades, es decir, tablas en su base de datos, modeladas como clases en Java. Además, también es posible incrustar el comportamiento en estas clases y, por lo tanto, lograr un modelo de dominio rico en comportamiento. Las entidades en este modelo pueden tener múltiples propósitos, incluido el propósito de reemplazar DTO para transportar datos entre niveles.
Dicho esto, hay lugares donde los marcos ORM pueden no ajustarse directamente al problema, especialmente cuando el modelo de datos ya está establecido o cuando se trabaja con sistemas heredados donde mapear tablas de bases de datos a clases Java no es un ejercicio trivial. Y en ciertos casos, si uno necesita sintonizar absolutamente el SQL generado por el marco ORM, entonces los marcos ORM son generalmente un mal ajuste.
preguntas relacionadas
He estado leyendo en varios artículos lo que es JPA (Java Persistent API) y qué proveedor lo soporta (DataNucleus, JBoss Hibernate, etc.)
No tengo experiencia con ORM (mapeo relacional de objetos).
Lo que he hecho hasta ahora es escribir mis propias clases de base de datos usando DTO y DAO. Hasta ahora estoy contento con lo que tengo pero me gustaría saber por qué las personas usan JPA sobre el archivo Java que contiene SQL .
Para mí, tengo ganas de escribir la clase DAO, estaría bien, algo así como a continuación.
public class DAOUsers {
public void insertNewUser(DTO DtoUser) {
String query = "INSERT INTO users(username, address) " +
"VALUES(DtoUser.username , DtoUser.address)";
Executor.run(query);
}
}
Aprendí que JPA utiliza el lenguaje de consulta persistente de Java y JPQL y opera contra el objeto de entidad en lugar de hacerlo directamente con las tablas de base de datos.
Mi entendimiento (corríjanme si estoy equivocado) es que el objeto de entidad aquí es el mismo que mi objeto DTO (tipo de bean?)
Pero de todos modos ... ¿qué beneficio realmente da JPA por escribir SQL puro en mi archivo? Parece que usar anotaciones requeridas por JPA y hacer SQL no legible no me parece realmente atractivo.
por favor avíseme si necesita más aclaración, soy nuevo en este tema y me gustaría escuchar alguna opinión.
Lo que realmente beneficia a JPA es escribir SQL puro en mi archivo?
Estos son algunos de los beneficios:
JPA le permite evitar escribir DDL en un dialecto SQL de base de datos específico. En su lugar, escribe "mapeos" en XML o usando anotaciones Java.
JPA le permite evitar escribir DML en el dialecto SQL específico de la base de datos.
JPA le permite cargar y guardar objetos y gráficos Java sin ningún lenguaje DML.
Cuando necesita realizar consultas, JPQL le permite expresar las consultas en términos de las entidades Java en lugar de las tablas y columnas SQL (nativas).
En términos generales, JPA es más simple, más limpio y requiere menos mano de obra que las asignaciones manuscritas JDBC + SQL +. Cuanto más complicado sea su modelo de datos, más beneficioso será.
Sin embargo, si el rendimiento es una preocupación primordial , JPA tiende a interponerse en el camino al agregar capas entre su aplicación y la base de datos. Si su aplicación requiere que optimice manualmente a mano las consultas y esquemas de la base de datos nativa para maximizar el rendimiento, JPA probablemente no sea una buena opción.
Probablemente, JPA tampoco sea para ti si te sientes mucho más cómodo haciendo malabares con Java, JDBC y SQL en la misma aplicación, que con dejar que ORM se encargue de los detalles desordenados. (Pero si lo es, probablemente sea una minoría ...)
Además, como sabes el lema de Java: "Escribe una vez, corre a todas partes"
También con JPQL puede ejecutar sus consultas JPQL en cada base de datos (DB2, Oracle, etc.)
Aunque esta es una vieja pregunta, siento que merece una nueva respuesta. Soy un adoptante tardío de JPA, lo he estado usando de forma intermitente durante un par de años, y aunque he tenido mis momentos impresionados por la simplicidad de presentar una nueva aplicación, me he quedado decididamente impasible. con el rendimiento, la complejidad y la curva de aprendizaje necesarios para hacer JPA correctamente. Las respuestas en este hilo en realidad refuerzan mi posición.
En primer lugar, @vineet sugiere que "las entidades pueden tener múltiples propósitos" ... que he visto en producción y yo diría que es alentador por ORM. Tanto para la cohesión y el principio de responsabilidad única. En mi experiencia, agregar comportamientos a entidades de bases de datos es buscar problemas. Lo sé porque lo hice y viví para arrepentirme.
En segundo lugar, existen alternativas simples a la complejidad de JPA que proporcionan la capacidad de utilizar clases con un SGBDR sin toda la pesadez (y los problemas de rendimiento) causados por la falta de coincidencia que ORM intenta (sin éxito) resolver. Hemos estado utilizando herramientas de mapeo de clase relacional no JPA durante una década en una aplicación con más de 1,000 tablas y simplemente no vemos cómo JPA es una mejora sobre el acceso más directo a la base de datos. JPA oscurece el poder de la base de datos al agregar sobrecarga (en forma de anotaciones y JQL) al modelo de clase ... ¿no debería funcionar de la otra manera?
@water sugiere numerosas cosas que son verdaderas en teoría pero poco prácticas en la realidad. Por ejemplo, al haber cambiado bases de datos back-end tres veces, puedo asegurar a los lectores que no existen algunos ajustes de configuración y listo. Sugeriría, si invierte mucho tiempo manteniendo su capa de persistencia, su modelo de base de datos está evolucionando, y estaría haciendo el mismo o más trabajo en JPA. ¡Particularmente cuando las consultas no triviales en JPA requieren el uso de JQL!
Casi todos pretenden que los desarrolladores de JPA no necesitan saber SQL. Lo que he visto en la práctica es que ahora tenemos que aprender SQL y JQL. Aparentemente no tenemos que hacer DDL, pero en cualquier aplicación no trivial, por supuesto , necesitas saber DDL. Hibernate ni siquiera recomienda usar la generación automática de DDL. Aparentemente no tenemos que hacer DML, excepto cuando llamamos a una consulta nativa, que por supuesto no es portátil, destruye la memoria caché y tiene todos los mismos problemas que JDBC ...
En definitiva, en una aplicación adecuadamente estructurada donde el modelo de dominio es independiente de la lógica comercial, JPA proporciona muy poco en cuanto a funcionalidad para lo que considero que es una curva de aprendizaje muy alta, porque el modelo de dominio es realmente muy fácil de construir . No usaría JDBC directamente, pero algo como Apache DBUtils proporciona una capa simple por encima de JDBC que correlaciona filas con objetos, y con un poco de esfuerzo puede proporcionar la mayoría de las ventajas de JPA sin ocultar y sin la sobrecarga.
He estado desarrollando aplicaciones de bases de datos Java desde JDBC 1.0, usando una variedad de bibliotecas (e iODBC y ESQL antes de JDBC), y solo por razones de rendimiento, he terminado con JPA. Pero incluso si el rendimiento fue mejor, la curva de aprendizaje y las abstracciones incompletas me dan una pausa seria. JPA es complejo e intenta ocultar detalles que, en mi opinión, los desarrolladores realmente deben preocuparse. Como ejemplo, recientemente vimos hibernate emitir 250 comandos de eliminación a la base de datos cuando uno sería suficiente. JPA, por su naturaleza, hace que este tipo de error sea fácil.
No estoy abogando por JDBC, simplemente estoy abogando en contra de JPA. Los desarrolladores que no pueden o no pueden trabajar en SQL probablemente no deberían estar escribiendo aplicaciones relacionales, del mismo modo que los Desarrolladores como yo, que no podían hacer álgebra matricial para salvar mi vida, deberían escribir juegos en 3D. Los desarrolladores que usan SQL para ganarse la vida deberían horrorizarse ante el SQL contorsionado que hibernate, por ejemplo, envía al servidor, para evitar viajes redondos que no deberían ser necesarios en primer lugar.
Como todos sabemos, ese objeto es uno de los más importantes de nuestra vida y en objeto de programación es una manera muy fácil de simplificar cualquier problema .... y si el objeto está disponible, entonces ¿por qué utilizamos todo en lugar de esa pequeña parte de eso? cosa significa objeto ....
- Si está codificando manualmente sentencias de SQL en su aplicación empresarial, está gastando una cantidad significativa de su tiempo de desarrollo actualizando y manteniendo su capa de persistencia.
En persistencia, ==> no hay más necesidad de API JDBC para el conjunto de resultados o el manejo de datos. ==> Ayuda a reducir las líneas de código, &&&&&& ==> Se abstrae nuestra aplicación de la base de datos SQL subyacente y el dialecto sql. El cambio a otra base de datos SQL requiere pocos cambios en el archivo de configuración de Hibernate (Write once / run-anywhere).
Si se hace correctamente, puede mapear consultas SQL directamente a objetos Java con implementaciones JPA como hibernar. Hace poco hice un proyecto en el que tenía un POJO y 3 o 4 anotaciones y un poco de código de configuración para tomar un procedimiento almacenado y asignarlo directamente a una lista de objetos (del tipo de clase POJO). Esto para mí es parte del poder de JPA.
Si lo está usando como si fuera SQL + JDBC, no sé de ninguna ventaja.
Aquí hay un artículo decente sobre las ventajas de JPA.
Espero que esto ayude.