java - ejemplo - JPA vs Spring JdbcTemplate

spring jdbctemplate application properties

Question

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:

• nuevo esquema de base de datos vs esquema y tablas preexistentes
• nivel de experiencia del desarrollador
• facilidad con la que se puede integrar con una capa de almacenamiento en caché de datos
• actuación
• cualquier otro factor relevante a considerar?

Answer 1

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 brindarle exactamente lo que necesita a la velocidad adecuada.

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, tanto como sea 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 utilizar las 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.

Otra cosa que debes tener en cuenta es que te sientes cómodo con JDBC y tienes plazos, no tienes que subirte 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ás 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 mejor de Spring es que la traducción de excepción de excepciones de JPA a la jerarquía de excepciones de Dao de primavera funciona tanto con JPA como con jdbcTemplate. Entonces use JPA cuando tenga sentido y jdbcTemplate cuando tenga sentido.

Answer 5

Utilice Spring JdbcTemplate si no desea acceder a su esquema de 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 de base de datos exóticos 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.

De acuerdo con mi conocimiento, JPA se puede conectar más fácilmente a capas de almacenamiento en caché de datos, ya que el enfoque orientado a objetos hace que la identificación, actualización e invalidación de entradas de caché sea más fácil.

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 considerar es que, aunque con JPA, usted obtiene un modelo de dominio para su esquema de base de datos, a menudo necesitará usar clases de DTO adicionales. Usando JdbcTemplate puedes operar directamente con clases DTO.