JPA vs Spring JdbcTemplate

Question

Para un nuevo proyecto, ¿JPA es siempre 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:

• nuevo esquema de base vs preexistente esquema y las tablas
• nivel de experiencia desarrollador
• facilidad con la que puede integrarse con una capa de almacenamiento en caché de datos
• rendimiento
• otros factores relevantes a considerar?

Answer 1

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 más bajo, con más flexibilidad, pero probablemente también más repetitivo.

Spring JdbcTemplate se puede usar más fácilmente con esquemas exóticos de bases de datos y un enfoque de procedimiento almacenado. Con JPA, debe asegurarse de que el esquema de la base de datos se correlacione correctamente con el modelo de dominio.

Ambas tecnologías necesitan desarrolladores que conozcan bases de datos relacionales, SQL y transacciones. Con JPA, sin embargo, usted obtiene una complejidad más oculta.

Según tengo entendido, JPA se conecta 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 back-end basados ​​en JdbcTemplate, pero en la mayoría de los casos hay más código involucrado.

Otro aspecto a tener en cuenta es que, aunque con JPA obtiene un modelo de dominio para su esquema de base de datos, a menudo necesitará utilizar clases de DTO adicionales. Usando JdbcTemplate puedes operar directamente con clases DTO.

Answer 2

Estoy de acuerdo con @Timo. La única otra idea que añadiría/ampliaría es que ORM tiene una semántica diferente del acceso de sql puro a sus datos.

El objetivo de ORM es abstraer el hecho de que sus datos están en un DB, en la medida de lo posible. Cuando utiliza ORM correctamente, todas las operaciones de persistencia se tratan en una única capa (con suerte). Sus objetos modelo tendrán poco o ningún código de persistencia; el hecho de que esté utilizando ORM debe ser invisible para su modelo.

Debido a esto, ORM es muy bueno para facilitarle la vida a ciertos tipos de operaciones, a saber, simples operaciones CRUD. Puede cargar sus objetos 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 lógica comercial. Si usa JDBC, tendrá que 'hidratar' sus instancias de objeto 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 donde tuve que copiar un gráfico completo de objetos y guardar una nueva copia de esos objetos. Si hubiera usado ORM (como traté de hacer), tuve que cargar todos los objetos de la BD, luego copiarlos y luego guardar los nuevos objetos. Llevé demasiado tiempo.

La mejor solución fue simplemente usar operaciones basadas en jdbc y 'insertar mediante selección' de llamadas sql para crear las nuevas filas. Fue rápido, el código fue más simple.

La otra cosa a tener en cuenta es que usted 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 usted conoce. Debe familiarizarse con ORM, pero no necesariamente para un proyecto con grandes expectativas. Hay mucho que aprender y no es trivial: realmente estás intercambiando un conjunto de complejidades con otro en la opción de usar jdbc vs orm.

Answer 3

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 DB. Encuentro que la mayoría de las veces, mis aplicaciones utilizan vistas de BD donde empujo la mayoría de la lógica de negocios hasta. He colocado correctamente DAO que tienen implementaciones JdbcTemplate. Se siente "limpio" y la mayoría de los códigos repetitivos están ocultos por JdbcTemplate (y su documentación en línea parece MUCHO mejor que ORM). El tiempo limitado que he usado algo así como Hibernate, lo encontré cuando funcionó, me ahorró algo de tiempo ... pero cuando no funcionaba correctamente, me costó días de depuración "WTF". Nunca tuve que pasar más de 20 minutos depurando JdbcTemplate DAO Impls. Creo que la clave, como otros señalaron, es lo cómodo que está con SQL/Schema Design

Answer 4

No se menciona en las otras respuestas, pero está bien usar ambas. En mi aplicación utilizo JPA y JdbcTemplate, para las operaciones tipo crud utilizo JPA, pero para informar 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.entityManager.queryForList("SELECT .. ",SomeProjectPojo.class); 
    } 
} 

Lo bueno de la primavera es que la traducción excepción de las excepciones a la primavera de la APP Dao excepción jerarquía funciona tanto con APP y JdbcTemplate. Entonces use JPA cuando tenga sentido y jdbcTemplate cuando tenga sentido.

Answer 5

En el trabajo, utilizamos Hibernate JDBCTemplate porque tiene más flexibilidad. También tiene un mejor rendimiento que JPA porque no está "cargando" una gran cantidad de datos innecesarios en su aplicación.
En el caso de JDBCTemplate, sus habilidades de SQL hacen mucho para darle exactamente lo que necesita a la velocidad correcta.