Usare Hibernate in un progetto Struts

[francesco.muia]

Bè niente di + facile grazie a Maven :

1) Progetto Maven con Struts -> Hibernate che utilizza direttamente hibernate.
2) Progetto Maven con Struts -> Hibernate che si appoggia allo standard JPA
1a) Progetto eclipse standard come punto 1
2a) Progetto eclipse standard come punto 2

In tutti i progetti vi è configurata un action helloWorld.do che persiste un entity e poi effettua una query per ritrovarlo.
In tutti i progetti il database utilizzato e apache-derby, ma ovviamente si può configurare qualsiasi database cambiando le impostazioni (hibernate.cfg.xml progetti che utilizzano direttamente hibernate, persistence.xml per gli altri) e aggiungendo di driver specifico per quel database.

[enric_84]

Grazie Francesco, proverò e ti dirò.
Un paio di cose, io non conosco Maven, secondo te mi aiuta nella gestione del progetto, quindi scegliere uno tra gli esempi 1 o 2 ?

Se invece opto per i progetti 1a e 1b, è meglio utilizzare Hibernate classico senza JPA(quindi solo con file xml per eseguire il mapping) oppure usare Hibernate+JPA?

[francesco.muia]

Bè sull'utilità di maven si potrebbero scrivere righe e righe di opinioni, ovviamente sia positive che negative.
Se sceglierlo di utilizzarlo e quindi sobbacarti un ulteriore "cosa" da imparare sta a te, per quanto mi riguarda da quando ci siamo conosciuti io e maven, ormai diversi anni orsono, siamo deventati una coppia perfetta.....
Per quanto riguarda il fatto di utilizzare direttamente hibernate oppure utilizzare lo standard JPA anche qui bisognerebbe vedere che cosa hai bisogno di fare, sicuramente il vantaggio della seconda, ti permetterebbe volendo di cambiare, senza modificare nulla nel codice, l'implementazione JPA ( es passare da hibernate ad eclipselink etc...). Senza contare il fatto che anche adottando la seconda puoi sempre e comunque utilizzare hibernate come nel primo caso, ovviamente in questo caso il cambio di libreria è più laborioso.

[enric_84]

sicuramente il vantaggio della seconda, ti permetterebbe volendo di cambiare, senza modificare nulla nel codice, l'implementazione JPA ( es passare da hibernate ad eclipselink etc...).

Quando dici "di cambiare,senza modificare nulla nel codice, l'implementazione di JPA", forse intendi dire modificare le annotation all'interno delle classi Java che fanno uso dello standard JPA. Quest'ultimo non è, a quanto ne so io, uno standard di annotazioni da inserire sopra i metodi o le proprietà della classe per mappare le tabelle del DB, cosa che prima si faceva con un file xml (che giustamente mi hai anche riportato te nel progetto 1b)?

Senza contare il fatto che anche adottando la seconda puoi sempre e comunque utilizzare hibernate come nel primo caso, ovviamente in questo caso il cambio di libreria è più laborioso.

Vuoi dire che usando Hibernate+JPA bisogna aggiungere librerie sia di Hibernate che di JPA?

Ma ho un piccolo dubbio: per le operazioni di persistenza CRUD Hibernate utilizza un PersistenceContext, mentre con lo standard JPA un EntityManager. Ora, utilizzando Hibernate+JPA, cosa si utlizza per questo tipo di operazioni, PersistenceContext o EntityManager?

Grazie,
Enrico

[francesco.muia]

Allora cerco di farti un po' di chiarezza.
JPA è un standard (jsr 220 se ricordo bene) uno standard descrive esclusivamente in maniera astratta un "comportamento" nel senso che descrive le modalità in cui si possono effettuare determinate operazioni. Ora da uno standard nascono delle implementazioni come hibernate, eclipselink, open-jpa etc...
Quindi la differenza tra i progetti è appunto se lavorare direttamente con l'implementazione oppure attraverso le interfacce che JPA "impone" per esempio se guardi le action dei due progetti, nel caso in cui utilizzo direttamente hibernate utilizzo:

		SessionFactory sessionFactory = (SessionFactory) servlet.getServletContext().getAttribute(HibernatePlugin.KEY_NAME);
		Session session = sessionFactory.openSession();

Cioè un oggetto org.hibernate.Session per gestire la persistenza ( occhi qui ho usato un plugin per creare il Session context e salvarlo nel servlet context, la stessa cosa si può fare con JPA ma ho preferito non farlo).
Nel caso invece utilizzo l'interfaccia JPA allora avrò a che fare con un EntityManager che ha sua volta non farà altro che delegare all'implementazione ( l'oggetto Session si prima) le operazioni che invocherò su di esso. Da questo si può vedere che se tu nel primo caso un giorno volessi passare ad eclipselink, oltre a cambiare ovviamente i jar, dovrai anche modificare tutte le parti del codice in cui utilizzi l'oggetto Session in quanto ovviamente eclipselink non ha, mentre nel secondo caso la modifica dei jar non si ripercuote sul codice in quanto essendo tutte implementazioni di JPA entrambe "sanno" che devono soddisfare i metodi dell'interfaccia JPA.

P.S
i jar persistence.jar non è una dipendenza diretta dei progetti ( non si trova nelle lib) in quanto tutti gli application servlet e servlet container dispongono di esso.

[enric_84]

Ok, dopo questa piccola parentesi sugli standard la mia domanda è: io conosco hibernate e jpa, non eclipselink che per ora non ho tempo di imparare. La mia idea è sviluppare un applicativo web, e come strato di persistenza ero indeciso se usare Hibernate o lo standard JPA. Ora, siccome JPA è più recente, e siamo nel 2015, e con l'avvento di JPA si è cercato se non erro di eliminare il mapping del DB utilizzando le Annotation invece che xml, sarebbe più opportuno utilizzare per il mio progettino lo standard JPA+Hibernate o solo Hibernate?
Se tu dovessi sviluppare un applicativo web quale tecnologia sceglieresti? (A intutito dico che Maven+ Hibernate+ JPA, ci ho azzeccato? )

[francesco.muia]

Il concetto che non ti è chiaro è che non è JPA + Hibernate, hibernate è un implementazione JPA...
comunque tornando alla tua domanda, cosa userei per sviluppare un appl web, per prima cosa mi domanderei che esigenze ho lato persistenza ? JPA ha tutto quello che mi serve ? Quante volte dovrò usare direttamente per esempio l'oggetto Session perchè le api JPA non hanno quello che mi serve ?
Ti posso già dire che per quasi il 100% delle piccole e medie applicazioni sicuramente la scelta ricade su JPA. e comunque dato che me lo hai chiesto tu io aggiungerei un ulteriore strato dove sviluppare business Logic cioè utilizzerei gli EJB per quest'ultima.
Per quanto riguarda maven, io personalmente lo userei in quanto non ho il problema di doverlo imparare e quindi mi darebbe solo vantaggi.

[enric_84]

[QUOTE=francesco.muia;25285123]Il concetto che non ti è chiaro è che non è JPA + Hibernate, hibernate è un implementazione JPA...[QUOTE]
Scusa se insisto, vorrei ben capire, ma lo standard JPA non è nato DOPO Hibernate? Per JPA io intendo le @Annotation che si usa inserire nelle Entity

io aggiungerei un ulteriore strato dove sviluppare business Logic cioè utilizzerei gli EJB per quest'ultima.

A questo punto, secondo la tua suddivisione, in quanti strati sarà suddivisa la persistenza?

Per quanto riguarda maven, io personalmente lo userei in quanto non ho il problema di doverlo imparare e quindi mi darebbe solo vantaggi.

Io non ho mai usato Maven, puoi indicarmi un buon tutorial veloce e ben fatto(preferirei NON la documentazione ufficiale visto che ti propinano un sacco di teoria) anche in inglese può andar bene, basta che ci siano esempi SVOLTI di come si crea e gestisce un progetto in Eclipse usando Maven.

Ciao,
Enrico

[francesco.muia]

Si effettivamente hibernate "orm" è nato prima di JPA intorno al 2003 ed è nato appunto con lo scopo di semplificare la persistenza che si faceva tramite gli ejb 2.1,mentre il jsr 220 ( JPA 1.0) è stato rilasciato nel 2005 e già da quell'anno hibernate è stato modificato per aderire allo standard, infatti lo si può notare rispetto alle altre implementazioni in quanto presenta diciamo 2 modi per effettuare le configurazioni ( Hibernate.cfr.xml orm.xml per il mapping degli entity).

per quanto riguarda la suddivisione dei progetti io non intendevo suddividere la persistenza ma inserire un ulteriore strato per la gestione di essa.
Ti faccio un esempio, supponiamo che durante la submit di un form ti venga invocata un'action "x" di struts. Seguendo la mia logica l'action si dovrà occupare solo esclusivamente di validare i dati ( per validazione intendo questo campo è obbligatorio etc..) un eventuale fase di conversione ( ovviamente opzionale) dopo di che invocherà un ejb ( remoto o locale questo sta a te) ed esso si occuperà di ricevere i dati ed effettuare tutte le operazioni di cui si ha bisogno fino ad arrivare a persistere i dati.
I principali vantaggi di questo "modello" è che avendo lo strato di logica indipendente dalla parte di view ( potrebbero anche stare persino in due server diversi) ti consente di avere, volendo, più tipi di view per la tua applicazione,per esempio un interfaccia grafica fatta in swing, un app per telefono etc... Senza dover modificare nulla del tuo codice. Questo prescindendo da tutte le caratteristiche degli ejb ( JTA, Injection etc...).
Ovviamente non ci sono solo vantaggi anche se l'unico svantaggio che mi viene in mente, a parte la "complicazione" di studiarli se non si conoscono, è che non ti basterà più un servlet container per la tua applicazione ma avrai bisogno di un application server.

Per quanto riguarda maven, scusa se te lo dico, ma sbagli approccio è proprio la teoria che uno deve avere bene in mente perchè una volta capito cosa è un repository, un plugin, i cicli di build, una dipendenza, un scm puoi tranquillamente , qualora si presentasse un problema cercare sul web la soluzione ( di materiale c'è n'è per tutti i gusti) è avendo chiara la "teoria" ti da la possibilità di capire la soluzione e adattarla al tuo caso specifico. Un consiglio se mi posso permettere incomincia prima ad usarlo da riga di comando, cioè non ti affidare fin da subito all'ide ( sia eclipse che netbeans hanno integrato anticamente maven ).

P.S
Ti posso chiedere come mai hai scelto struts per la view ?

[enric_84]

supponiamo che durante la submit di un form.....dopo di che invocherà un ejb ( remoto o locale questo sta a te) ed esso si occuperà di ricevere i dati ed effettuare tutte le operazioni di cui si ha bisogno fino ad arrivare a persistere i dati.

Proprio questo approccio di gestione persistenza(EJB+Struts) l'ho usato recentemente in un progettino di esempio che ho sviluppato poco tempo fa, se vuoi ti posso far vedere una piccola parte (te lo metto su GitHub), così mi dirai se nella applicazione nuova che ho intenzione di fare va bene la struttura o se c'è bisogno di un altro strato per gestire la persistenza.

Ovviamente non ci sono solo vantaggi anche se l'unico svantaggio che mi viene in mente, a parte la "complicazione" di studiarli se non si conoscono, è che non ti basterà più un servlet container per la tua applicazione ma avrai bisogno di un application server.

Già li conosco

Per quanto riguarda maven, scusa se te lo dico, ma sbagli approccio è proprio la teoria che uno deve avere bene in mente

Intendi la teoria di Java in generale o la teoria specifica di Maven?

P.S
Ti posso chiedere come mai hai scelto struts per la view ?

Anche in altri forum mi hanno chiesto il perchè di questa scelta, consigliandomi l'uso di altri framework come Spring o Vaadin(a detta loro molto migliori di Struts), e la mia risposta è la stessa che do a te: conosco Struts-1 e l'uso delle Struts View, ho scelto Struts per consolidare le mie conoscenze in quest'ambito, non per altro