Para un nuevo proyecto, ¿JPA siempre es la herramienta recomendada para manejar datos relacionales o hay escenarios en los que Spring JdbcTemplate es una mejor opción? Algunos factores a considerar en su respuesta:
Respuestas:
Use 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á usando 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 una complejidad más 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.
Llego un poco tarde a esta publicación, pero tiendo a usar JdbcTemplate sobre ORM. Sé SQL (bastante bien) y realmente no quiero ser "abstraído" de mi base de datos. Encuentro que la mayoría de las veces, mis aplicaciones usan vistas de base de datos donde empujo la mayor parte de la lógica empresarial hacia arriba. 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 dedicar más de 20 minutos a depurar las impls de JdbcTemplate DAO. Creo que la clave, como 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 capa fina (con suerte). Los objetos de su 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 sus objetos de modelo, presentarlos, actualizarlos, eliminarlos con bastante facilidad. Le facilita la vida 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' sus instancias de 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 tuve que copiar un gráfico de objeto completo y guardar una nueva copia de esos objetos. Si había usado ORM (como intenté hacer), tenía que cargar todos los objetos fuera de la base de datos, luego copiarlos y luego guardar los nuevos objetos. Tomé demasiado tiempo.
La mejor solución era simplemente usar operaciones basadas en jdbc e 'insertar mediante select' llamadas sql para crear las nuevas filas. Fue rápido, el código fue más simple.
La otra cosa a considerar es que se siente cómodo con JDBC y tiene fechas límite, 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 conoce. 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.
No se menciona en las otras respuestas, pero está bien usar ambas. En mi aplicación uso JPA y JdbcTemplate, para operaciones de tipo crud uso JPA pero para informes o donde es más fácil uso jdbcTemplate.
@Repository
public class FooRepository
{
@PersistenceContext
private EntityManager entityManager;
@Autowired(required = true)
private JdbcTemplate jdbcTemplate;
public void saveFoo(Foo foo)
{
this.entityManager.persist(foo);
}
public List<SomeReportPojo> getSomeReport()
{
return this.jdbcTemplate.queryForList("SELECT .. ",SomeProjectPojo.class);
}
}
Lo mejor de Spring es que la traducción de excepciones de las excepciones de JPA a la jerarquía de excepciones de Spring Dao funciona tanto con JPA como con jdbcTemplate. Así que use JPA cuando tenga sentido y jdbcTemplate cuando tenga sentido.
getSomeReport()que this.jdbcTemplate. ...en lugar de this.entityManager. ...?
En el trabajo usamos Hibernate JDBCTemplate porque tiene más flexibilidad. También tiene un mejor rendimiento que JPA porque no está "cargando" muchos datos innecesarios en su aplicación.
En el caso de JDBCTemplate, sus habilidades de SQL son importantes para brindarle exactamente lo que necesita a la velocidad correcta.