JPA vs Spring JdbcTemplate

Question

Per un nuovo progetto, JPA è sempre lo strumento consigliato per la gestione dei dati relazionali o ci sono scenari in cui Spring JdbcTemplate è una scelta migliore? Alcuni fattori da considerare nella reazione:

• nuovo schema del database vs preesistente schema e tabelle
• livello di competenza sviluppatore
• facilità con la quale può integrare con uno strato di caching dei dati
• prestazioni
• eventuali altri fattori rilevanti da considerare?

Answer 1

Utilizzare Spring JdbcTemplate se non si desidera accedere allo schema del database tramite un modello di dominio. Usando JdbcTemplate si sta utilizzando un accesso di livello inferiore, con maggiore flessibilità, ma probabilmente anche più standard.

Spring JdbcTemplate può essere utilizzato più facilmente con schemi di database esotici e un focus di stored procedure. Utilizzando JPA è necessario assicurarsi che lo schema del database sia mappato correttamente al modello di dominio.

Entrambe le tecnologie richiedono che gli sviluppatori conoscano database relazionali, SQL e transazioni. Con JPA si ottiene però una maggiore complessità nascosta.

JPA è a mia conoscenza più facilmente collegabile ai livelli di memorizzazione nella cache dei dati, poiché il focus orientato agli oggetti rende più semplice l'identificazione della cache, l'aggiornamento e l'invalidazione.

È possibile perfezionare i backend basati su JdbcTemplate, ma per la maggior parte dei casi è necessario più codice.

Un altro aspetto da considerare è che, sebbene con JPA si ottenga un modello di dominio per lo schema del database, sarà spesso necessario utilizzare classi DTO aggiuntive. Usando JdbcTemplate puoi operare direttamente con le classi DTO.

Answer 2

Sono d'accordo con @Timo. L'unica altra intuizione che vorrei aggiungere/ampliare è che ORM ha una semantica diversa dall'accesso di sql ai dati.

Il punto di ORM è di astrarre il fatto che i dati sono in un DB affatto, per quanto possibile. Quando si utilizza correttamente l'ORM, tutte le operazioni di persistenza vengono gestite in uno strato sottile (si spera). Gli oggetti del modello avranno un codice di persistenza minimo o inesistente; il fatto che stai usando ORM dovrebbe essere invisibile al tuo modello.

Per questo motivo, ORM è molto utile per semplificare la vita a determinati tipi di operazioni, ovvero semplici operazioni CRUD. Puoi caricare i tuoi oggetti modello, presentarli, aggiornarli, cancellarli abbastanza facilmente. Ti semplifica la vita perché quando accedi ai tuoi dati, ottieni gli oggetti del modello, su cui puoi scrivere la logica di business. Se si utilizza JDBC, sarà necessario "idratare" le istanze dell'oggetto dai dati, che possono essere complicate e soggette a errori.

ORM non è sempre la scelta migliore. JPA è uno strumento per un lavoro, se lo strumento non è sufficiente per il lavoro si vorrà trovare uno strumento migliore. Ad esempio, ho avuto uno scenario in cui ho dovuto copiare un intero oggetto grafico e salvare una nuova copia di quegli oggetti. Se avessi usato ORM (come ho provato a fare), ho dovuto caricare tutti gli oggetti dal DB, quindi copiarli, quindi salvare i nuovi oggetti. Ho impiegato troppo tempo.

La soluzione migliore era semplicemente utilizzare le operazioni basate su jdbc e "inserire tramite select" le chiamate sql per creare le nuove righe. Era veloce, il codice era più semplice.

L'altra cosa da considerare è che sei a tuo agio con JDBC, e hai scadenze, non devi saltare sul carrozzone ORM. Le classi Spring JdbcTemplate sono estremamente potenti e utili. A volte lo strumento migliore per il lavoro è quello che conosci. Dovresti familiarizzare con ORM, ma non necessariamente per un progetto con grandi aspettative. C'è molto da imparare e non è banale - in realtà stai scambiando un insieme di complessità con un altro nella scelta di usare jdbc vs orm.

Answer 3

Sono un po 'in ritardo per questo post, ma tendo ad usare JdbcTemplate su ORM. Conosco SQL (abbastanza bene) e davvero non voglio essere "astratto" dal mio DB. Trovo che la maggior parte delle volte le mie app utilizzino visualizzazioni DB in cui spingo la maggior parte della logica aziendale fino a. Ho DAO correttamente stratificato che hanno implementazioni JdbcTemplate. Sembra "pulito" e la maggior parte del codice boilerplate è nascosto da JdbcTemplate (e la sua documentazione online sembra MOLTO migliore di quella degli ORM). Il tempo limitato in cui ho usato qualcosa come Hibernate, l'ho trovato quando ha funzionato, mi ha risparmiato un po 'di tempo ... ma quando non funzionava correttamente, mi è costato giorni di debug "WTF". Non ho mai dovuto spendere più di 20 minuti per il debug di JDbcTemplate DAO impls. Penso che la chiave, come altri hanno notato, è quanto sei comodo con SQL/Schema Design

Answer 4

Non è menzionato nelle altre risposte, ma va bene usare entrambi. Nella mia app uso JPA e JdbcTemplate, per le operazioni di tipo greggio io uso JPA ma per i report o dove è più semplice io 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); 
    } 
} 

La cosa grandiosa di primavera è che la traduzione fatta eccezione eccezioni JPA alla primavera eccezione Dao gerarchia funziona sia con JPA e jdbcTemplate. Quindi usa JPA quando ha senso e jdbcTemplate quando ha senso.

Answer 5

Al lavoro usiamo Hibernate JDBCTemplate perché ha una maggiore flessibilità. Ha anche prestazioni migliori rispetto a JPA perché non stai "caricando" un sacco di dati inutili nella tua app.
Nel caso JDBCTemplate, le tue competenze SQL ti aiutano molto a darti esattamente ciò di cui hai bisogno alla giusta velocità.