Al fin luego de tanto luchar hemos dado con la solución de este atolladero que agunos usuarios de esta web han tenido. Si deseas compartir algo no dudes en compartir tu conocimiento.
Solución:
Utilice Spring JdbcTemplate si no desea acceder al esquema de su base de datos a través de un modelo de dominio. Al usar JdbcTemplate, está utilizando un acceso de nivel inferior, con más flexibilidad, pero probablemente también más repetitivo.
Spring JdbcTemplate se puede usar más fácilmente con esquemas de bases de datos exóticos y un enfoque de procedimiento almacenado. Al usar JPA, debe asegurarse de que el esquema de la base de datos se asigne correctamente al modelo de dominio.
Ambas tecnologías necesitan desarrolladores que conozcan bases de datos relacionales, SQL y transacciones. Sin embargo, con JPA obtienes más complejidad oculta.
Que yo sepa, JPA se puede conectar más fácilmente a las capas de almacenamiento en caché de datos, ya que el enfoque orientado a objetos facilita la identificación, actualización e invalidación de entradas de caché.
Puede ajustar mejor los backends basados en JdbcTemplate, pero en la mayoría de los casos hay más código involucrado.
Otro aspecto a considerar es que aunque con JPA obtiene un modelo de dominio para el esquema de su base de datos, a menudo necesitará usar clases DTO adicionales. Usando JdbcTemplate puede operar directamente con clases DTO.
Llegué un poco tarde a esta publicación, pero tiendo a usar JdbcTemplate sobre ORM. Conozco SQL (bastante bien) y realmente no quiero que me “abstraigan” de mi base de datos. Encuentro que la mayoría de las veces, mis aplicaciones usan vistas de base de datos donde presiono la mayor parte de la lógica comercial. Tengo DAO en capas correctamente que tienen implementaciones de JdbcTemplate. Se siente “limpio” y la mayoría del código repetitivo está oculto por JdbcTemplate (y su documentación en línea parece MUCHO mejor que las cosas de ORM). El tiempo limitado que he usado algo como Hibernate, descubrí que cuando funcionaba, me ahorraba algo de tiempo… pero cuando no funcionaba correctamente, me costaba días de depuración “WTF”. Nunca he tenido que pasar más de 20 minutos depurando impls JdbcTemplate DAO. Pienso que el keycomo señalaron otros, es lo cómodo que se siente con SQL/Schema Design
Estoy de acuerdo con @Timo. La única otra idea que agregaría/ampliaría es que ORM tiene una semántica diferente del acceso sql puro a sus datos.
El objetivo de ORM es abstraer el hecho de que sus datos están en una base de datos, tanto como sea posible. Cuando usa ORM correctamente, todas las operaciones de persistencia se tratan en una (con suerte) capa delgada. Sus objetos modelo tendrán poco o ningún código de persistencia; el hecho de que esté utilizando ORM debería ser invisible para su modelo.
Debido a esto, ORM es muy bueno para facilitarle la vida a ciertos tipos de operaciones, a saber, operaciones CRUD simples. Puede cargar los objetos de su modelo, presentarlos, actualizarlos, eliminarlos con bastante facilidad. Hace su vida más fácil porque cuando accede a sus datos, recupera los objetos del modelo, en los que puede escribir la lógica empresarial. Si usa JDBC, tendrá que ‘hidratar’ las instancias de su objeto a partir de los datos, lo que puede ser complicado y propenso a errores.
ORM no siempre es la mejor opción. JPA es una herramienta para un trabajo, si la herramienta no es suficiente para el trabajo, querrá encontrar una herramienta mejor. Por ejemplo, tuve un escenario en el que tenía que copiar un gráfico de objeto completo y guardar una nueva copia de esos objetos. Si hubiera usado ORM (como traté de hacer), tenía que cargar todos los objetos fuera de la base de datos, luego copiarlos y luego guardar los nuevos objetos. Tardé demasiado.
La mejor solución fue simplemente usar operaciones basadas en jdbc e ‘insertar a través de select’ llamadas sql para crear las nuevas filas. Era rápido, el código era más simple.
La otra cosa a considerar es que se siente cómodo con JDBC y tiene plazos, no tiene que subirse al carro de ORM. Las clases Spring JdbcTemplate son extremadamente poderosas y útiles. A veces, la mejor herramienta para el trabajo es la que conoces. Debe familiarizarse con ORM, pero no necesariamente para un proyecto con altas expectativas. Hay mucho que aprender y no es trivial: realmente está intercambiando un conjunto de complejidades con otro en la elección de usar jdbc vs orm.
Sección de Reseñas y Valoraciones
Eres capaz de respaldar nuestro quehacer añadiendo un comentario o dejando una puntuación te damos las gracias.