JPA vs Spring JdbcTemplate

Llego un poco tarde a este post, pero tiendo a usar JdbcTemplate sobre OR. Conozco SQL (bastante bien) y realmente no quiero ser "abstraído" lejos de mi base de datos. Me parece que la mayoría de las veces, mis aplicaciones están utilizando vistas de base de datos donde empuje la mayoría de la lógica de negocios hasta. Tengo DAOs con capas adecuadas que tienen implementaciones 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 OR). El tiempo limitado que he usado algo como Hibernar, descubrí cuando funcionó, me ahorró algo de tiempo...pero cuando no funcionaba correctamente, me costó días de depuración "WTF". Nunca he tenido 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 el diseño SQL / Schema

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

El objetivo de OR es abstraer el hecho de que sus datos están en una base de datos, tanto como sea posible. Cuando se utiliza properly 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 OR debe ser invisible para su modelo.

Debido a esto, OR es muy bueno para facilitar su vida para ciertos tipos de operaciones, a saber, operaciones simples CRUD. Puede cargar los objetos de su modelo, presentarlos, actualizarlos, eliminarlos con bastante facilidad. Le hace la vida más fácil porque cuando accede a sus datos, obtiene objetos de modelo de vuelta, en los que puede escribir lógica de negocio. Si utiliza JDBC, tendrá que 'hidratar' sus instancias de objetos a partir de los datos, lo que puede ser complicado y propenso a errores.

OR es no siempre la mejor opción. JPA es una herramienta para un trabajo, si la herramienta no es suficiente para el trabajo, querrá encontrar una mejor herramienta. Por ejemplo, tuve un escenario en el que tuve que copiar un gráfico de objetos completo y guardar una nueva copia de esos objetos. Si había usado OR (como traté de hacer), tenía que cargar todos los objetos de la base de datos, luego copiarlos y luego guardar los nuevos objetos. Tardé demasiado.

La mejor solución era simplemente usar operaciones basadas en jdbc e' insertar a través de select ' sql llamadas 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 OR. Las clases Spring JdbcTemplate son extremadamente potentes y útiles. A veces la mejor herramienta para el trabajo es la que conoces. Debe familiarizarse con OR, pero no necesariamente para un proyecto con altas expectativas. Hay mucho que aprender, y no es trivial, realmente usted están negociando un conjunto de complejidades con otro en la elección de usar jdbc vs or.

No se menciona en las otras respuestas, pero está bien usar ambas. En mi Aplicación utilizo JPA y JdbcTemplate, para operaciones de tipo crud utilizo JPA pero para informes o donde es más fácil utilizo 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 Spring es que la traducción de excepciones de JPA a spring Dao exception hierarchy funciona tanto con JPA como con JdbcTemplate. Así que use JPA cuando tenga sentido y JdbcTemplate cuando tenga sentido.

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 SQL van un largo camino en darle exactamente lo que necesita a la velocidad correcta.