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 tua risposta:
Risposte:
Utilizza Spring JdbcTemplate se non desideri accedere allo schema del database tramite un modello di dominio. Usando JdbcTemplate stai usando un accesso di livello inferiore, con maggiore flessibilità, ma probabilmente anche più boilerplate.
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 venga mappato correttamente al modello di dominio.
Entrambe le tecnologie richiedono che gli sviluppatori conoscano database relazionali, SQL e transazioni. Con JPA ottieni però una complessità più nascosta.
Per quanto ne so, JPA è più facilmente collegabile ai livelli di memorizzazione nella cache dei dati, poiché il focus orientato agli oggetti semplifica l'identificazione, l'aggiornamento e l'invalidazione delle voci della cache.
È possibile ottimizzare meglio i backend basati su JdbcTemplate, ma per la maggior parte dei casi è coinvolto 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. Utilizzando JdbcTemplate puoi operare direttamente con le classi DTO.
Sono un po 'in ritardo per questo post, ma tendo a 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 utilizzano viste DB in cui spingo la maggior parte della logica aziendale. Ho DAO correttamente stratificati che hanno implementazioni JdbcTemplate. Sembra "pulito" e la maggior parte del codice boilerplate è nascosto da JdbcTemplate (e la sua documentazione in linea sembra MOLTO migliore della roba ORM). Il tempo limitato che ho usato qualcosa come Hibernate, ho scoperto che quando ha funzionato, mi ha fatto risparmiare 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 eseguire il debug di JdbcTemplate DAO impls. Penso che la chiave, come altri hanno notato, sia quanto sei a tuo agio con SQL / Schema Design
Sono d'accordo con @Timo. L'unica altra intuizione che vorrei aggiungere / espandere è che ORM ha una semantica diversa dal puro accesso sql ai tuoi dati.
Lo scopo di ORM è quello di astrarre il più possibile il fatto che i tuoi dati si trovino in un DB. Quando si utilizza correttamente ORM, tutte le operazioni di persistenza vengono gestite in un (si spera) sottile strato. Gli oggetti del modello avranno poco o nessun codice di persistenza; il fatto che stai usando ORM dovrebbe essere invisibile al tuo modello.
Per questo motivo, ORM è molto bravo a semplificarti la vita per determinati tipi di operazioni, vale a dire semplici operazioni CRUD. Puoi caricare gli oggetti del tuo modello, presentarli, aggiornarli, eliminarli abbastanza facilmente. Ti semplifica la vita perché quando accedi ai tuoi dati, ottieni indietro gli oggetti del modello, su cui puoi scrivere la logica di business. Se utilizzi JDBC, dovrai "idratare" le istanze degli oggetti dai dati, il che può essere complicato e soggetto a errori.
ORM non è sempre la scelta migliore. JPA è uno strumento per un lavoro, se lo strumento non è sufficiente per il lavoro, vorrai trovare uno strumento migliore. Ad esempio, avevo uno scenario in cui dovevo copiare un intero oggetto grafico e salvare una nuova copia di quegli oggetti. Se avessi usato ORM (come ho provato a fare), dovevo caricare tutti gli oggetti dal DB, quindi copiarli, quindi salvare i nuovi oggetti. Ho impiegato troppo tempo.
La soluzione migliore era semplicemente usare le operazioni basate su jdbc e le chiamate sql "inserisci tramite selezione" 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 delle scadenze, non devi saltare sul carro dell'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: stai davvero scambiando un insieme di complessità con un altro nella scelta di usare jdbc vs orm.
Non è menzionato nelle altre risposte ma va bene usarli entrambi. Nella mia App utilizzo JPA e JdbcTemplate, per operazioni di tipo crud utilizzo JPA ma per la reportistica o dove è più semplice utilizzo 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);
}
}
La cosa grandiosa di Spring è che la traduzione delle eccezioni dalle eccezioni JPA alla gerarchia delle eccezioni di Spring Dao funziona sia con JPA che con jdbcTemplate. Quindi usa JPA quando ha senso e jdbcTemplate quando ha senso.
getSomeReport()essere this.jdbcTemplate. ...invece di this.entityManager. ...?
Al lavoro usiamo Hibernate JDBCTemplate perché ha una maggiore flessibilità. Ha anche prestazioni migliori di JPA perché non stai "caricando" molti dati non necessari nella tua app.
Nel caso di JDBCTemplate, le tue abilità SQL fanno molto per darti esattamente ciò di cui hai bisogno alla giusta velocità.