2010-11-01 16 views
47

Saluti, Attualmente in fase di sviluppo di un'applicazione di servizi Web di piccole dimensioni in cui la risposta dal servizio Web (utilizzando CXF + Spring) viene elaborata e salvata nel database. Per lavorare con il database sto usando Hibernate (3.5). Navigando su un esempio di Hibernate + Spring sul web, spesso vedo l'uso di HibernateTemplate quindi sono un po 'confuso su questo momento e volevo chiedere:Spring hibernate template quando usare e perché?

Usi HibernateTemplate nelle tue applicazioni Hibernate3? Quando HibernateTemplate può migliorare la tua vita di sviluppo e in base a quali punti posso decidere devo usarlo o no?

Grazie.

risposta

50

Tutti i modelli a molla (ibernazione, JDBC, riposo, JPA etc.) hanno gli stessi vantaggi e svantaggi:

Pro: essi svolgono routine di configurazione comuni per voi, farvi saltare la boilerplate e concentrarsi sul logica che vuoi

Con: si sta accoppiando la vostra applicazione strettamente alla struttura della molla. Per questo motivo, Spring consiglia di non utilizzare più HibernateTemplate.

In particolare, ciò che HibernateTemplate ha fatto per te era di aprire e chiudere automaticamente sessioni e operazioni di commit o rollback dopo l'esecuzione del codice. Tuttavia, tutto ciò può essere realizzato in modo orientato all'aspetto usando Spring Declarative Transaction Management.

Riferimento:


Aggiornamento:

A partire dalla primavera 3.1 (e versioni più recenti), HibernateTemplate has been removed. Vedere Hibernate per i modelli di utilizzo attualmente suggeriti.

+0

Grazie per i collegamenti e per aver detto che HibernateTemplate non è consigliato ora, credo che andrò con la modalità di transazione dichiarativa. – artjomka

+0

Buona idea. L'approccio modello è ancora valido per REST, JMS, LDAP e probabilmente altri, ma per ORM, l'approccio transazionale è più potente e anche più semplice. –

+13

Con il supporto Hibernate 4 di Spring 3.1, HibernateTemplate non è più semplicemente "sconsigliato"; è stato completamente eliminato. Vedi https://jira.springsource.org/browse/SPR-8096 – SteveT

4

HibernateTemplate racchiude un numero di elementi per semplificarti la vita.

È la tua scelta se utilizzarlo o meno. Del resto, puoi lavorare con un database senza Hibernate. Il materiale JDBC di Spring è molto buono. Potresti trovare più facile risolvere il tuo problema senza dover imparare Hibernate.

+0

A medio-lungo termine, l'utilizzo di Hibernate è molto più intelligente e più produttivo. Seguire l'avanzamento della risposta di cui sopra sarebbe pericoloso. Raccomando di imparare e usare Hibernate. –

+1

Pericoloso? Ridicolo. Penso che il commento sopra sia esilarante. Raccomando di usare lo strumento giusto per il lavoro. – duffymo

+0

Sono stati avviati molti progetti 'solo usando JDBC, perché è più semplice'. Tuttavia avrebbe dovuto essere avviato con Hibernate, perché dopo 2 settimane sarebbe stato più efficiente. –

10

Permettetemi di chiarire una cosa che Spring's HibernateTemplate non sarà supportata in futuro, questo significa che le versioni di Hibernate 4+ non supportano HibernateTemplate. Quindi si consiglia di utilizzare declarative transaction management come suggerito da Sean.

+0

Vedi questo quando stai leggendo la raccomandazione di HibernateTemplate di Duffy, BTW. Non è nemmeno supportato più. –

+1

Chiunque legga questo dovrebbe notare che è venuto DUE ANNI dopo la mia risposta originale. La chiaroveggenza non è nella mia cassetta degli attrezzi. – duffymo

0

Il pattern OpenSessionInViewFilter è efficace. Si apre una sessione di sospensione & che si collega al thread durante l'elaborazione di ogni richiesta. OpenSessionInView estende anche la Session e la caricabilità al rendering View & del livello View, che diminuisce la complessità dell'aggancio & (abilitando tale opzione a 'funziona').

Le mie filosofie non sono davvero d'accordo con la gestione delle transazioni basata su aspetti/dichiarazioni. Mi piace rendere "espliciti" importanti eventi di cambiamento di stato/ciclo di vita, poiché dovrebbero essere assolutamente definiti - non debolmente dipendenti da più livelli nascosti & indiretti, che potrebbero funzionare o meno.

Fornisce un punto per eseguire il debug su.

Il commit TX è solo una riga di codice; ma è il più importante su cui vuoi arrivare. Non più sintatticamente di una dichiarazione "transazionale"; ma molto più definito.

Sinceramente trovo che "comandi utente" o "richieste", che sono il luogo corretto per avviare una transazione dal punto di vista della transazione, devono essere ben strutturati, ben identificati & piuttosto espliciti all'interno dell'applicazione.

(ho avuto problemi a trovare la roba aspetto di classe di carico di lavoro, cercando, quando è uscito prima. La mia valutazione è che rispetto al codice OO ben scritto, aspetto è limitata solo valore marginale.)

Suggerimento: Generalmente faccio una lezione di supporto, per rendere davvero conveniente per ottenere la Sessione & per eseguire la Transazione.

HbHelper o somesuch.

+1

-1 per l'assurdità totale espressa in "non debolmente dipendente da strati magici ariosi, che possono o meno funzionare" – duffymo

+0

Fammi sapere quando puoi piazzare un breakpoint sul tuo commit, @duffymo. Puoi anche dire ai bambini * come avresti iniziato a eseguire il debug di questo .. quando le cose non funzionavano perfettamente *. E forse ti piacerebbe anche spiegare come la sintassi dichiarativa sia 'più breve' della scrittura di 'HbHelper.commit() ''. –

+0

Non fraintendermi: ci possono essere argomenti a favore di questa tecnologia. Ma mi piace pesare i pro e i contro reali. E il codice esplicito, è definitivamente più affidabile e più debuggabile. Saresti un pazzo a pensare diversamente. –

0

Tutti i modelli saranno deprecati andando avanti. Meglio usare il gestore di entità che è lo standard di JPA.