HIBERNATE OPEN SOURCE OBJECT/RELATIONAL MAPPING IMPLEMENTATION FOR JAVA PERSISTENCE

Transcript

1 UNIVERSITÀ DEGLI STUDI DI FIRENZE FACOLTÀ DI INGEGENRIA DIPARTIMENTO DI SISTEMI E INFORMATICA HIBERNATE OPEN SOURCE OBJECT/RELATIONAL MAPPING IMPLEMENTATION FOR JAVA PERSISTENCE Jacopo Torrini torrini@dsi.unifi.it Laboratorio di tecnologie del software

2 Indice generale Hibernate 2 1 Introduzione La persistenza in Java Persistenza nelle applicazioni object-oriented Paradigm mismatch Problema della granularità Problema dei sottotipi Problema dell'identità Problema delle associazioni Problema della navigabilità delle associazioni Il problema delle n+1 select ORM Introduzione ad Hibernate Un esempio di applicazione con Hibernate Mapping di una classe con una tabella di un database Configurazione di Hibernate Mapping delle classi persistenti Associazioni tra entità Associazioni many-to-one Associazioni one-to-many Associazioni bidirezionali Ereditarietà Table per concrete class Table per class hierarchy Table per subclass Generazione automatica del database Persistenza con Hibernate Persistence Manager Perisitence lifecycle Identità degli oggetti Persistence Manager Persistenza transitiva Interrogazioni con Hibernate Recuperare oggetti per Id Interrogazioni con HQL Un esempio pratico Installazione dei prerequisiti Java Eclipse Hibernate HSQLDB Creazione di un nuovo progetto Creazione delle classi del dominio Creazione del file di configurazione di Hibernate Creazione dei file di mapping Utilizzo di Hibernate in una classe Test Appendice: lo standard JPA...40

3 3 Capitolo

4 1 Introduzione

5 5 Capitolo 1 Introduzione La persistenza è uno dei concetti fondamentali nello sviluppo di applicazioni sia web che desktop. L'approccio utilizzato nella gestione di dati persistenti rappresenta una decisione chiave che impatta radicalmente sui tempi di sviluppo, la portabilità e la manutenibilità dell'applicazione. Quando si parla di persistenza con Java, si intende normalmente la memorizzazione di dati su un database relazionale con l'utilizzo del linguaggio SQL tramite un'insieme di interfacce standard. Se da un lato questo approccio permette di utilizzare convenientemente tutte le potenzialità offerte dai database relazionali, accedendo anche a quelle funzioni proprietarie che li rendono più performanti o più adatti al particolare caso d'uso, dall'altro introduce una serie di problematiche che vanno dall'obbligo di scrivere ogni query, persino per le operazioni più elementari CRUD (Create Read Update e Delete) col linguaggio SQL, la non portabilità su altri database relazionali dovuta ai vari dialetti di questi ultimi ed infine la differenza tra la rappresentazione di dati del mondo object-oriented e quella del mondo relazionale. A proposito dell'ultimo problema Martin Fowler in [POEAA] propone un'insieme di pattern architetturali per il mapping tra i database relazionali e linguaggi object-oriented. In seguito Gaving King e Christian Bauer forniscono un'implementazione per Java di questi concetti, dando vita al progetto open source Hibernate ([HIA], [JPWH]).

6 2 La persistenza in Java

7 7 Capitolo 2 La persistenza in Java In Java l'accesso ad un database relazionale viene normalmente effettuato tramite le API JDBC (Java Database Connectivity). L'SQL può essere scritto a mano direttamente nel codice Java, o può essere generato al volo durante l'esecuzione del programma. Le operazioni possibili sono operazioni di basso livello, quali l'esecuzione di una query, la valorizzazione dei parametri della query, la possibilità di scorrere tra i risultati dell'interrogazione o leggere il valore dei suoi campi. Nelle applicazioni in ambito Enterprise l'interesse maggiore si concentra soprattutto sul problema della modellazione dei dati e della business logic. In questi ambiti applicativi il codice di accesso ai dati risulta spesso un'operazione meccanica e tediosa, prona ad errori e di difficile manutenibilità. Quello che serve è la possibilità di persistere grafi complessi di oggetti senza occuparsi degli aspetti implementativi di basso livello. Perché allora utilizzare un database relazionale? I database relazionali dominano il mercato della gestione della persistenza dei dati, e di solito sono un requisito e non una scelta progettuale. Sono molti anni che vengono studiati e ottimizzati, rendendoli strumenti performanti e affidabili. Inoltre la stessa base di dati può essere utilizzata da più applicazioni scritte con linguaggi differenti non necessariamente object-oriented. 2.1 Persistenza nelle applicazioni object-oriented Nelle applicazioni object-oriented la persistenza permette agli oggetti di vivere oltre i confini del processo che li ha creati, e gli oggetti possono essere salvati sul disco e ripristinati su richiesta. In questo ambito applicativo, soprattutto quando si utilizza un domain model ([POEAA]), lo stato dell'applicazione è definito da grafi di oggetti tra loro interconnessi. Un'applicazione non lavora quindi direttamente con una rappresentazione tabulare dei suoi dati, contrariamente a quello che succede in una base di dati relazionale, la logica applicativa risiede completamente nella parte Java e non nelle stored procedures del database e viene fatto uso di concetti complessi come l'ereditarietà, il polimorfismo e la composizione. Di contro le operazioni SQL, quali le proiezioni o le join, hanno come risultato rappresentazioni tabellari dei dati. Le differenze presentate vengono comunemente definite dal termine paradigm mismatch, e meritano un'analisi dettagliata. Nel seguito verranno presentate solamente le problematiche derivanti dal paradigm mismatch, mentre nei prossimi capitoli saranno descritte le soluzioni che Hibernate propone. 2.2 Paradigm mismatch Problema della granularità Nel cercare di far corrispondere proprietà di un oggetto Java con colonne di un database relazionale si deve affrontare il problema della differenza di granularità delle due rappresentazioni. Se ad esempio si vuole persistere un oggetto Address, attributo della classe User, su una tabella USERS, è molto probabile che al singolo oggetto Address corrispondano più colonne della tabella USERS, quali la via, il cap, il numero civico ecc. Nonostante che i database relazionali supportino gli user-defined datatypes (UDT), che permettono di creare anche dalla parte relazionale tipi di dato strutturati come Address, l'uso di queste funzionalità rende non molto portabile l'applicazione.

8 2.2.2 Problema dei sottotipi Hibernate 8 In Java, come in tutti i linguaggi object-oriented, l'ereditarietà permette di definire una classe a partire da una superclasse: la sottoclasse eredita attributi e metodi della superclasse. Inoltre un'associazione può essere polimorfica: se ad esempio un attributo di una classe è di tipo A, si può assegnare a tale attributo un'istanza una classe B sottoclasse di A. Nonostante alcuni database definiscano il concetto di type ineritance, la maggior parte di essi non permette l'uso di tabelle che ereditano i campi da altre tabelle. In generale comunque un database non può definire un'associazione polimorfica, in quanto una foreign key viene definita tra un campo di una tabella e una e una sola tabella target Problema dell'identità Quando due oggetti o due record di una tabella devono essere confrontati per determinare se sono identitci, esistono approcci diversi tra gli oggetti Java e i record di un database. In Java abbiamo il concetto di identity, quando due riferimenti sono associati alla stessa istanza di oggetto, e di equality, quando due istanze differenti possono essere considerate uguali per valore (ad esempio il confronto tra due stringhe). Nei database relazionali l'identità di una riga è specificata direttamente dalla chiave primaria della tabella. Spesso la chiave primaria non rappresenta nemmeno un valore caratterizzante la riga, ma serve esclusivamente per individuare in modo univoco il record (chiave surrogata) Problema delle associazioni Nei linguaggi object oriented le associazioni tra entità sono implementate con le object references. Ma nel mondo relazionale un associazione è rappresentata da una foreign key. I riferimenti sono per loro natura direzionali, per cui se si necessita di bidirezionalità nell'associazione, è necessario implementare due riferimenti incrociati, uno per oggetto. Le foreign key invece non hanno direzionalità, rappresentano solo un legame tra record di due tabelle. Per quanto rigurarda la molteplicità delle associazioni, esiste un enorme differenza tra le due rappresentazioni: se da un lato non è semplice determinare la molteplicità di un associazione di una classe Java (ad esempio distinguere one-to-one da many-to-one), differentemente dalle associazioni di un database relazionale, nel mondo object-oriented le associazioni possono essere più complesse: associazioni one-to-many o many-to-many, rappresentate da una collezione di riferimenti ad oggetti. Nei database relazionali queste associazioni non sono possibili o almeno hanno una rappresentazione differente: le associazioni one-to-many non possono essere implementate, devono essere ribaltate come associazioni many-to-one, poiché non è possibile avere un campo che rappresenta una collezione di chiavi esterne. Inoltre le associazioni many-to-many devono essere implementate con una tabella aggiuntiva di associazione Problema della navigabilità delle associazioni Come detto in precedenza, un'istanza di un oggetto Java ha di solito associazioni ad istanze di altri oggetti. Queste associazioni creano un grafo di oggetti strettamente interconnessi. Tramite l'uso di metodi getter dell'oggetto è possibile ottenere le istanze degli oggetti associati, permettendo in pratica la navigabilità tra gli oggetti del grafo.

9 9 Capitolo 2 La persistenza in Java Tutto questo non ha un corrispondente nel mondo relazionale. Quando si esegue una query, si devono stabilire i confini di estrazione dei dati, inserendo nell'interrogazione le join necessarie tra le tabelle da cui estrarre i dati. Una volta eseguita, la query non è modificabile nella struttura per cui non è possibile estendere la ricerca ad altre tabelle se non rieseguendo una nuova query. Un sistema che si prefigge di creare un mapping tra il mondo object-oriented e quello relazionale deve risolvere alcuni meccanismi di interrogazione automatica durante l'esplorazione del grafo degli oggetti. Poiché non è pensabile che il database venga completamente caricato in memoria all'inizializzazione dell'applicazione, è chiaro che il grafo degli oggetti, il cui stato è persistito nel database, deve essere in qualche modo limitato e confinato. Solo durante l'esplorazione delle associazioni, in maniera automatica, devono essere fatte nuove interrogazioni al database per inizializzare rami del grafo di oggetti (ed effettivamente Hibernate fa questo). Sebbene questo meccanismo sembri allettante, nasconde un problema di efficienza piuttosto grosso, problema che, se non affrontato, rischia di rendere estremamente inefficiente un'applicazione. Il problema è conosciuto col nome di n+1 select problem Il problema delle n+1 select 2.3 ORM Si supponga che un oggetto Parent abbia un'associazione uno a molti con una classe Child. Nel caso in cui si debbano richiedere n oggetti di tipo Parent, il numero di query necessarie per avere gli oggetti completamente inizializzati è pari a n+1, di cui: 1 query è necessaria per ottenere le istanze degli oggetti Parent, mentre n servono per inizializzare ciascuna collezione di Child contenuta in ogni Parent. Se si dovesse pensare all'equivalente operazione fatta in un database relazionale, basterebbe una singola query che mette in join il parent e il child per avere tutti i dati richiesti. Object Relational Mapping è il sistema di persistenza automatico e trasparente di oggetti in tabelle di un database relazionale. Ogni oggetto viene persistito nel database tramite l'inserimento di nuovi record i cui campi contengono i valori degli attributi dell'oggetto. Di solito ad ogni oggetto corrisponde un record di una particolare tabella associata alla classe dell'oggetto. L'associazione tra la classe e la tabella viene ottenuta tramite l'utilizzo di file di descrizione (file di mapping), in cui si specificano le modalità di mapping tra gli attributi dell'oggetto e i campi della tabella. Ogni interrogazione viene effettuata utilizzando un linguaggio simil-sql che permette di scrivere query utilizzando il nome delle classi e degli attributi. Le interrogazioni vengono convertite dal tool ORM in istruzioni SQL da eseguire sul database relazionale sottostante. I resultset delle interrogazioni vengono convertiti nei corrispondenti oggetti in maniera del tutto trasparente. Dal punto di vista dello sviluppatore uno strumento ORM permette di effettuare delle richieste di istanze di particolari classi, con filtri basati sulle proprietà delle classi, i cui risultati sono liste di oggetti. Tutti i dettagli sottostanti al livello object-oriented sono praticamente nascosti. In definitiva una soluzione ORM consiste in: API per eseguire le operazioni di base (CRUD) sugli oggetti delle classi persistenti

10 Hibernate 10 Un linguaggio per la costruzione di query sulle classi e le proprietà delle classi Un sistema per specificare il mapping tramite metadata Un sistema interno per l'interazione con oggetti transazionali, per il dirty checking, il fetching delle associazioni lazy. I benefici che si hanno nell'utilizzo di una soluzione ORM sono svariati: Produttività: il codice che si occupa della persistenza dei dati è la parte forse più tediosa di un'applicazione. Un tool ORM elimina molto di questo codice, semplificandolo e automatizzandolo al massimo Manutenibilità: dovendo scrivere meno codice è più facile manutenere l'applicazione. Inoltre in soluzioni fatte a mano, che trasformano il modello ad oggetti in query relazionali e record di database in oggetti, è molto più difficile far variare il modello di dominio insieme al modello relazionale. Con un tool ORM si mantengono separati i due modelli tramite l'uso di uno strato intermedio di mapping, che spesso minimizza anche la propagazione di variazione tra i due modelli. Performance: anche se a prima vista sembra che lo strato aggiuntivo di mapping introduca dei perggioramenti alla performace, ci sono talmente tante opzioni di ottimizzazioni (utilizzo di cache di primo e secondo livello, utilizzo di batch query ecc) che in realtà, in applicazioni con un numero elevato di accessi in lettura, è possibile ottenere delle performance estremamente più efficienti di una semplice soluzione basata su SQL. Indipendenza dal tipo di database: questa è una delle caratteristiche più interessanti di uno strumento di ORM, il quale astrae l'applicazione dal sottostante database SQL e dal suo dialetto. ORM introduce un linguaggio proprietario per le interrogazioni e le operazioni CRUD. Questo linguaggio viene poi convertito automaticamente nell'sql del database sottostante. Cambiano un parametro nella configurazione dell'orm, è possibile portare l'applicazione su altri database senza praticamente toccare una riga di codice. Inoltre l'orm conosce molto bene (spesso molto meglio del programmatore) il dialetto del particolare database, e ottimizza le query utilizzando quanto più possibile funzioni SQL proprietarie.

11 3 Introduzione ad Hibernate

12 Hibernate 12 Hibernate cerca di essere una soluzione completa al problema della gestione di dati persistenti in Java. Si pone nel mezzo tra l'applicazione e un database relazionale, lasciando lo sviluppatore libero di concentrarsi sugli aspetti di business dell'applicazione. Hibernate non è una soluzione intrusiva e si adatta bene ad applicazioni nuove ed esistenti, e non richiede modifiche distruttive al resto dell'applicazione. 3.1 Un esempio di applicazione con Hibernate Prima di approfondire i concetti fondamentali per l'utilizzo di Hibernate, è utile dare un occhiata al codice per eseguire operazioni di base di tipo CRUD, giusto per avere un'idea della complessità di utilizzo. Questo esempio mostra come rendere persistenti e come ottenere la lista di istanze di una classe User. Definiamo la classe User: Listato 3.1: La classe User public class User{ private Long id; private String name; private String lastname; public User() { public User( String name, String lastname ){ this.name = name; this.lastname = lastname; public Long getid(){ return id; public void setid( Long id ){ this.id = id; public String getname(){ return name; public void setname( String name ){ this.name = name; public String getlastname(){ return lastname; public void setlastname( String lastname ){ this.lastname = lastname; Il codice che salva su database un'istanza di User è il seguente

13 13 Capitolo 3 Introduzione ad Hibernate Listato 3.2: Rendere persistente un'istanza User user = new User( Beppe, Rossi ); Session session = getsessionfactory().opensession(); Transaction tx = session.begintransaction(); session.save( user ); tx.commit(); session.close(); Ovviamente sono stati omessi tutti i dettagli relativi al metodo getsessionfactory(), al mapping tra la classe User e il database e non è ancora stato spiegato cosa sono gli oggetti Session e Transaction, interfacce definite in Hibernate. Dall'esempio risulta chiara comunque la semplicità con cui si rende persistente un oggetto Java: si istanzia, si apre una transazione, si chiama il metodo save() di Session e si esegue il commit della transazione. Niente di più. L'oggetto Java verrà persistito sul DB nella tabella associata alla classe User, come nuovo record della tabella. Ogni proprietà dell'oggetto sarà salvata in una colonna distinta della tabella. L'esempio che segue restituisce l'istanza di User il cui id (di tipo Long) è pari a 10: Listato 3.3: Ricerca per Id Session session = getsessionfactory(); Transaction tx = session.begintransaction(); User users = (User) session.get( User.class, new Long(10) ); tx.commit(); session.close(); Per recuperare tutte le istanze di User salvate nel database: Listato 3.4: Lista di tutti gli User Session session = getsessionfactory(); Transaction tx = session.begintransaction(); List<User> users = session.createquery( select u from User u ).list(); tx.commit(); session.close(); Infine per cancellare un'istanza persistente: Listato 3.5: Cancellazione di un'istanza User user =... //user e' un istanza persistente caricata dal database Session session = getsessionfactory(); Transaction tx = session.begintransaction(); session.delete( user ); tx.commit(); session.close();

14 3.2 Mapping di una classe con una tabella di un database Hibernate 14 Come introdotto nel precedente capitolo, per rendere persistente una classe è necessario specificare un mapping tra la classe e il database. Hibernate utilizza dei file XML per definire questa associazione 1. Ogni classe persistente ha il suo file di mapping associato. Di solito il file XML sta nello stesso package della classe persistente e ha lo stesso nome della classe con estensione.hbm.xml. Il file di mapping per User ha quindi nome User.hbm.xml. Listato 3.6: User.hbm.xml <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" " <hibernate-mapping package="domain"> <class name="user" table="users" > <id name="id" column="id" type="long"> <generator class="native" /> </id> <property name="name" column="name" type="string" /> <property name="lastname" column="last_name" type="string" /> </class> </hibernate-mapping> Al di là dei dettagli sull'intestazione del file XML, è possibile notare come il mapping venga definito tramite: un elemento <class> in cui è specificato il nome della classe Java e la tabella corrispondente del database. All'interno di <class> si trova la definizione dell'id dell'oggetto tramite l'elemento <id>, in cui si definisce quale sia la politica di generazione di tale id. Nell'esempio viene definito un id con una politica che delega al database sottostante il compito di creare l'id (ad esempio un campo auto-increment) tramite l'elemento <generator class= native >. Seguono poi le definizioni delle proprietà tramite l'elemento <property>, ognuna delle quali viene mappata con una colonna della tabella. Non tutto quello che è stato scritto sul file XML è necessario. Hibernate è in grado, ad esempio, di inferire il tipo di dato a partire dalla proprietà della classe Java, rendendo superfluo l'attributo type dell'elemento <property>. Pure l'attributo column, che specifica il nome della colonna associata, può essere omesso. Così facendo Hibernate assume che la colonna abbia lo stesso nome della proprietà. 3.3 Configurazione di Hibernate Per poter utilizzare Hibernate deve essere costruita innanzitutto una SessionFactory. La SessionFactory, come dice il nome, è la factory che permette la creazione di una Session di Hibernate, la quale può essere vista in maniera semplicistica come la cache delle istanze di oggetti Java persistenti e permette l'interazione con il database (la Session viene trattata in 1 Esiste un'alternativa all'utilizzo dei file XML per la creazione del mapping, ossia l'utilizzo delle Java annotations. Questo presuppone l'utilizzo di una distribuzione Java uguale o superiore alla 5 e l'utilizzo di alcune librerie aggiuntive che rendono Hibernate un'implementazione per JPA (si veda a tal proposito 8 Appendice: lo standard JPA

15 15 Capitolo 3 Introduzione ad Hibernate maniera approfondita nel seguito). La SessionFactory deve essere creata una sola volta, è molto dispendiosa a livello di risorse e contiene tutti gli aspetti di configurazione per l'accesso ad un database. La SessionFactory viene configurata attraverso un file XML di nome hibernate.cfg.xml che normalmente risiede nella root del classpath: Listato 3.7: hibernate.cfg.xml <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" " <hibernate-configuration> <session-factory> <property name="hibernate.connection.driver_class">com.mysql.jdbc.driver</property> <property name="hibernate.dialect">org.hibernate.dialect.mysqldialect</property> <property name="hibernate.connection.url">jdbc:mysql://localhost/testdb> <property name="hibernate.connection.username">testdbuser</property> <property name="hibernate.connection.password">testdbpasswd</property> <property name="hibernate.connection.provider_class"> org.hibernate.connection.c3p0connectionprovider </property> <property name="hibernate.c3p0.min_size">5</property> <property name="hibernate.c3p0.max_size">20</property> <property name="hibernate.c3p0.timeout">300</property> <property name="hibernate.c3p0.max_statements">50</property> <property name="hibernate.c3p0.idle_test_period">3000</property> <mapping resource="domain/user.hbm.xml" /> </session-factory> </hibernate-configuration> Il file specifica: il driver JDBC di connessione al database il tipo di dialetto per il particolare database da usare; cambiando dialetto e driver è possibile usare un qualsiasi altro database (tra quelli supportati da Hibernate, e sono davvero tanti) senza modificare assolutamente l'applicazione I parametri di connessione al database Il gestore del pool di connessioni al database (in questo caso c3p0) I file di mapping (hbm.xml) da usare per definire le classi persistenti La SessionFactory viene inizializzata tramite le seguenti righe di codice: Listato 3.8: Inizializzazione della SessionFactory Configuration cfg = new Configuration(); SessionFactory sessionfactory = cfg.configure().buildsessionfactory(); Come già detto, la SessionFactory deve essere istanziata una sola volta (almeno una per database utilizzato all'interno della stessa applicazione) e deve essere accessibile in ogni parte dell'applicazione in cui è necessario interagire con un oggetto di tipo Session. Per

16 Hibernate 16 questo normalmente la SessionFactory viene incapsulata dentro un singleton ([GOF]) o, in ambito di applicazioni web, come risorsa JNDI ([JNDIT]) o come variabile di una sessione HTTP.

17 4 Mapping delle classi persistenti

18 Hibernate 18 Una delle cose interessanti che differenziano Hibernate da altri sistemi di persistenza (ad esempio gli entity beans nella vecchia specifica EJB2) consiste nel fatto che le classi che devono essere rese persistenti, e qui in seguito chiamate entità, non devono implementare alcuna interfaccia. In pratica un qualsiasi modello di dominio composto da semplici classi Java (comunemente chiamate POJO, Plain Old Java Objects) possono essere rese persistenti con Hibernate. La persistenza in Hibernate è trasparente, ossia gli oggetti Java non conoscono assolutamente il database sottostante e non conoscono nemmeno il loro stato di persistenza. Il meccanismo di persistenza è esternalizzato verso un persistence manager (la Session di Hibernate). La trasparenza di Hibernate in realtà impone alcune specifiche sulle classi da persistere: ogni classe deve avere il costruttore di default e, a meno di altre configurazioni particolari, Hibernate usa metodi setter e getter per impostare i valori nelle proprietà di un oggetto. Questa limitazione è del tutto plausibile, anche perché normalmente ogni oggetto Java implementa i metodi richiesti da Hibernate. Infine, tutti gli attributi che rappresentano una collezione di oggetti devono utilizzare l'interfaccia della collezione (ad esempio Set o List) e non una delle loro implementazioni (HashSet o ArrayList), ma anche questa è una buona pratica di progettazione di una classe di dominio. 4.1 Associazioni tra entità Associazioni many-to-one In un modello di dominio ogni classe ha un'insieme di attributi i cui valori possono essere o un dato primitivo, includendo anche per estensione quegli attributi il cui tipo è assimilabile ad un dato primitivo (String, Date, Long, Integer ecc), o un'associazione ad un'entità, ossia un oggetto il cui tipo è una classe persistente del modello di dominio (per adesso si ignorano le collezioni di oggetti). Come visto in precedenza, il mapping dei dati primitivi è definito, nel file di mapping associato alla classe persistente, tramite l'elemento <property>, assegnando il corretto valore all'attributo type. Quando invece un attributo è un riferimento ad un'altra classe del modello di dominio, abbiamo un'associazione tra entità. Le associazioni tra entità vengono rappresentate, nel mondo relazionale, con relazioni many-to-one. Infatti se ogni classe del modello di dominio corrisponde ad una tabella del database, la relazione tra due entità altro non è che l'associazione tra due tabelle fatte tramite foreign key. Riprendendo l'esempio del paragrafo 3.2 Mapping di una classe con una tabella di un database, viene aggiunta una nuova entità, la classe Department, che rappresenta il diparitmento di appartenenza dell'utente. La classe User viene aumentata con un riferimento ad un'istanza di Department. User Department La classe Department sarà così definita:

19 19 Capitolo 4 Mapping delle classi persistenti Listato 4.1: La classe Department public class Department{ private Long id; private String name; private int depcode; public Department(){ public Long getid(){ return id; public void setid( Long id ){ this.id = id; public String getname(){ return name; public void setname( String name ){ this.name = name; public int getdepcode(){ return depcode; public void setdepcode( int depcode ){ this.depcode = depcode; La classe User viene così modificata (le parti in grassetto sono le aggiunte): Listato 4.2: La classe User modificata public class User{ private Long id; private String name; private String lastname; private Department department; public User() {... //metodi getter e setter dei vecchi attributi public Department getdepartment(){ return department; public void setdepartment( Department department ){ this.department = department; Il file di mapping per Department è il seguente:

20 Hibernate 20 Listato 4.3: Department.hbm.xml <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" " <hibernate-mapping package="domain"> <class name="department" table="departments" > <id name="id" column="id" type="long"> <generator class="native" /> </id> <property name="name" column="name" type="string" /> <property name="depcode" column="dep_code" type="integer" /> </class> </hibernate-mapping> Il file di mapping di User viene modificato in questo modo (le parti aggiunte sono in grassetto): Listato 4.4: User.hbm.xml modificato <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" " <hibernate-mapping package="domain"> <class name="user" table="users" > <id name="id" column="id" type="long"> <generator class="native" /> </id> <property name="name" column="name" type="string" /> <property name="lastname" column="last_name" type="string" /> <many-to-one name= department class= Department column= dep not-null= true /> </class> </hibernate-mapping> Questo secondo file contiene l'elemento <many-to-one>, il quale definisce l'associazione tra la classe User e la classe Department come molti-a-uno tra le due tabelle corrispondenti. Nel database la relazione tra l'utente e il dipartimento viene implementata tramite la chiave esterna definita dal campo dep della tabella USERS. Da notare l'attributo not-null, che specifica la nullabilità della proprietà, rafforzando a livello di codice Java i vincoli del campo del database, permettendo così ad Hibernate di controllare che non ci siano vincoli non soddisfatti prima dell'inserimento nel database. Inoltre questo attributo permette di far stabilire ad Hibernate la precedenza di salvataggio delle entità in caso di persistenza transitiva (si veda 5.5 Persistenza transitiva) Associazioni one-to-many Con Hibernate è possibile gestire attributi che sono collezioni di entità. Nel modello di dominio questi attributi devono essere definiti tramite l'interfaccia che definisce il tipo di collezione (Collection, List, Set, ecc), e sono specificati nel file di mapping tramite un elemento di tipo <bag>, <set> o <list>. Si supponga ad esempio che il modello di dominio sia rappresentato dalla seguente

21 21 Capitolo 4 Mapping delle classi persistenti associazione tra User e Department: User Department In questo caso non abbiamo più l'associazione tra User e Department, bensì un attributo di tipo Set di User (non si accettano duplicati) nella classe Department. Listato 4.5: La classe Department modificata public class Department{ private Long id; private String name; private int depcode; private Set<User> users = new HashSet<User>(); public Department(){... //metodi getter e setter public Set<User> getusers(){ return users; public void setusers( Set<User> users ){ this.users=users; La prima cosa che deve essere notata è che nei database relazionali questo tipo di associazione non esiste. Il legame tra le tabelle permette di specificare una sola foreign key per campo verso i record di un'altra tabella. Le tabelle del database quindi non subiscono alcuna modifica, e la relazione è sempre implementata dalla chiave esterna definita sul campo dep della tabella USERS. Nel mondo Java il modello viene invece ribaltato e si concentra l'attenzione sulla relazione di aggregazione tra il dipartimento e i suoi utenti. Il file di mapping di Department viene così modificato:

22 Hibernate 22 Listato 4.6: Department.hbm.xml modificato <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" " <hibernate-mapping package="domain"> <class name="department" table="departments" > <id name="id" column="id" type="long"> <generator class="native" /> </id> <property name="name" column="name" type="string" /> <property name="depcode" column="dep_code" type="integer" /> <set name="users" table="users" lazy="true"> <key column="dep" not-null="true" /> <one-to-many class="user" /> </set> </class> </hibernate-mapping> L'elemento <set> è composto da: l'attributo name, nome della proprietà l'attributo table, nome della tabella associata l'attributo lazy, che se impostato a true permette di non inizializzare subito la collezione quando l'oggetto viene caricato dal database; la collezione verrà valorizzata quando vi si accederà per la prima volta l'elemento <key> che definisce la chiave esterna nella tabella USERS l'element <one-to-many> che definisce il set come una relazione tra entrità one to many e l'entità contenuta nella collezione è del tipo User Associazioni bidirezionali Le relazioni many-to-one e one-to-many appena viste possono essere fuse insieme per creare una relazione bidirezionale. Normalmente è utile modificare il modello delle classi in modo da avere nella classe dalla parte one (quella che contiene la collezone) un metodo add che si occupa di aggiungere alla collezione il nuovo elemento e di impostare nell'elemento un riferimento all'oggetto a cui si aggiunge: Listato 4.7: Aggiunte alla classe Department... public void adduser( User user ){ users.add( user ); user.setdepartment( this );... La relazione bidirezionale contiene un problema di aggiornamento multiplo: se specifichiamo nei file di mapping sia la proprietà many-to-one sia quella one-to-many, abbiamo due rappresentazioni differenti alla stessa foreign key. Per cui l'aggiunta di un nuovo utente ad un dipartimento viene intesa da Hibernate come un doppio aggiornamento

23 23 Capitolo 4 Mapping delle classi persistenti alle istanze persistenti. Hibernate non rileva trasparentemente il fatto che due modifiche si riferiscono alla stessa colonna di database, poiché non è stato ancora indicato da alcuna parte la bidirezionalità dell'associazione. Per fare in modo che venga effettuato un solo update è necessario aggiungere l'attributo inverse all'elemento <set> di Department.hbm.xml. Con questa indicazione, Hibernate considererà solamente le modifiche fatte dalla parte di User, e in particolare quando viene settato l'attributo department. Le aggiunte fatte solo dalla parte della collezione di Department verranno ignorate: Listato 4.8: Department.hbm.xml con l'attributo inverse <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" " <hibernate-mapping package="domain"> <class name="department" table="departments" > <id name="id" column="id" type="long"> <generator class="native" /> </id> <property name="name" column="name" type="string" /> <property name="depcode" column="dep_code" type="integer" /> <set name="users" table="users" lazy="true" inverse="true"> <key column="dep" not-null="true" /> <one-to-many class="user" /> </set> </class> </hibernate-mapping> 4.2 Ereditarietà Una delle problematiche introdotte nel paragrafo 2.2 Paradigm mismatch che un tool di ORM deve affrontare è il mapping di classi che appartengono ad una gerarchia di ereditarietà. Hibernate offre almeno tre soluzioni differenti di mapping: Table per concrete class: Si usa una tabella per ogni classe concreta (non astratta). Table per class hierarchy: Si usa una sola tabella per tutte le classi di una gerarchia. Table per subclass: Si usa una tabella per ogni classe, concreta o astratta che sia Table per concrete class Tutte le proprietà delle superclassi sono inserite nella tabella associata alla classe concreta. Questo tipo di mapping non supporta molto bene le associazioni polimorfiche. Si supponga ad esempio di avere una classe Client che ha un'associazione con una classe Super, super-classe di una gerarchia di altre due classi Sub1 e Sub2. Le tabelle risultanti saranno solo 3, chiamate rispettivamente C, S1 e S2. Risulta impossibile determinare quale sia la tabella della gerarchia di classi verso cui associare la foreign key di C, in quanto non esiste una tabella associata a Super e la scelta di una tra S1 o S2 sarebbe ovviamente errata.

24 4.2.2 Table per class hierarchy Hibernate 24 Una intera gerarchia di classi viene mappata in un'unica tabella. Tutte le proprietà della gerarchia di classi vengono fuse insieme. Un campo della tabella serve da discriminante per determinare il tipo di classe associato al record. Hibernate istanzia correttamente la classe concreta tenendo conto di quest'ultimo. I vantaggi di questo approccio sono diversi: è possibile usare associazioni polimorfiche a oggetti di gerarchie di classi mappate con questa strategia. Infatti nella stessa tabella coesistono record associati a istanze di tipo diverso. L'interrogazione è molto veloce poiché include una sola tabella (a differenza del prossimo tipo di mapping che utilizza più tabelle) Di contro nella stessa tabella confluiscono campi associati a proprietà di classi che possono stare su rami differenti della stessa gerarchia. Questi possono avere senso per un ramo e non averne per un altro. Per cui Hibernate ha bisogno di poter rendere nulli tutti quei campi dei record per cui essi non hanno motivo di esistere. Questo comporta di dover rendere nullabili tutti i campi che si differenziano nella gerarchia, perdendo un'importante funzionalità di controllo dei valori di un campo Table per subclass L'ultima opzione è quella in cui si crea una tabella per ogni classe della gerarchia, che sia astratta o meno. Le tabelle vengono messe in join con una foreign key sulla chiave primaria. Ogni volta che viene fatto un inserimento, le proprietà di ogni classe della gerarchia vengono suddivise in più record, ognuno dei quali viene salvato nella tabella corrispondente. Le interrogazioni vengono effettuate eseguendo una outer join su gli id di tutte le tabelle incluse nella gerarchia. In questo modo i record che vengono recuperati sono composti dall'unione di tutti i campi di tutte le tabelle, ma ogni record ha valorizzati (diversi da null) soltanto i campi che hanno senso per il tipo di oggetto da istanziare associato al record. L'aspetto positivo di questo modello è che è completamente polimorfico. Inoltre può evolvere in maniera naturale insieme all'aggiunta di nuove classi nella gerarchia: è sufficiente aggiungere una nuova tabella in join con quella della superclasse. Il lato negativo è che le interrogazioni possono subire (a seconda del database sottostante) dei rallentamenti, in quanto le outer join sono più dispendiose. 4.3 Generazione automatica del database Un aspetto interessante di Hibernate è la capacità di generare il database a partire dai file di mapping. Effettivamente i file di mapping contengono tutte le informazioni necessarie per costruire lo schema. Inoltre, nel file di mapping, è possibile specificare ulteriori attributi per definire alcune caratteristiche che deve avere il campo associato del database (ad esempio per una string è possibile specificare la lunghezza del campo VARCHAR associato. Questa funzionalità risulta estremamente utile in fase di sviluppo. Dato che il tipo di database sottostante può essere cambiato senza problemi, è possibile utilizzare, in fase di debug o per i test unitari, delle implementazioni leggere di database (ad esempio HSQL che può essere creato anche in memoria). Ogni volta che si esegue il test hibernate crea il database da zero, senza bisogno di mantenere allineato a mano il modello di dominio e lo schema del DB.

25 5 Persistenza con Hibernate

26 Hibernate Persistence Manager La persistenza in Hibernate si ottiene tramite il Persistence Manager. Tramite il Persistence Manager gli oggetti Java possono essere salvati, trovati ed eliminati dal database. Esso controlla pure le transazioni del database e degli aspetti di cache degli oggetti persistenti. In Hibernate il Persistence Manager è implementato da un'oggetto di tipo Session. 5.2 Perisitence lifecycle Un oggetto Java non è reso persistente nel momento in cui viene istanziato. Un oggetto inizialmente non è associato al database e il suo stato si dice essere transient. Nel momento in cui l'oggetto è collegato al Persistence Manager allora si dice che è persistent. Ci sono due modi per rendere persistente un oggetto: chiamare il metodo save della Session di Hibernate o recuperare un'istanza dal database tramite le funzioni di ricerca del Persistence Manager. Una volta che un oggetto è persitente, ogni cambiamento al suo stato viene propagato anche al database. In realtà queste modifiche nei record del database avvengono solo in determinati momenti stabiliti da Hibernate stesso. Questa caratteristica prende il nome di transparent transaction-level-write-behind, ossia Hibernate propaga le modifiche il più tardi possibile, ma nasconde i dettagli all'applicazione. Se la sessione a cui è associato un oggetto persistente viene chiusa (eseguendo il commit delle operazioni) o se l'oggetto viene sganciato dal Persistence Manager tramite appositi metodi di Session, l'oggetto entra nello stato detached. Un oggetto detached è sempre associato al database (il suo id non è nullo) ma le modifiche effettuate sull'oggetto non vengono propagate al database. Un oggetto detached può tornare ad essere persistente, riagganciando l'oggetto alla sessione tramite appositi metodi. Quando un oggetto persistente viene cancellato, esso viene rimosso dal database e il suo stato torna ad essere transiente. 5.3 Identità degli oggetti Per chiarire uno dei punti che fanno parte del paradigm mismatch, ossia il problema dell'identità, è interessante analizzare come Hibernate gestisca le istanze persistenti. Prima di affrontare la questione, è importante tenere presente la differenza che c'è tra database identity ( a.getid().equals(b.getid()) ) e object identity.( a == b ). In Hibernate vale il seguente principio: All'interno di una Session di Hibernate esiste una sola istanza di oggetto che rappresenta una particolare riga di una tabella del database Questo principio, comunemente detto transaction-scoped identity, ci garantisce che se richiediamo due volte lo stesso record del database otteniamo sempre la stessa istanza di oggetto Java. Quindi nell'ambito dello stesso persistence manager la database identity equivale alla object identity.

27 27 Capitolo 5 Persistenza con Hibernate 5.4 Persistence Manager In questo paragrafo vengono presentati alcuni esempi di utilizzo della Session di Hibernate per rendere persistent, detached e transient alcuni oggetti Java. Per l'esempio prendiamo la classe User definita nel Listato 3.1: La classe User. Listato 5.1: Oggetti persistenti User user = new User( Franco, Rossi ); Session session = getsessionfactory().opensession(); Transaction tx = session.begintransaction(); session.save( user ); tx.commit(); session.close(); L'oggetto user viene creato e attaccato alla Session di Hibernate tramite il metodo save, passando in questo modo allo stato persistent. Questo produce, ad un certo momento, un insert di un nuovo record nella tabella USERS. Conclusa la transazione la sessione viene chiusa e l'oggetto diventa detached. Se la sessione non viene chiusa, l'oggetto rimane nello stato persistent ed è quindi possibile modificarlo ulteriormente. Le modifiche verranno rese persistenti alla fine di una nuova transazione: Listato 5.2: Modifiche ad un oggetto persistente User user = new User( Franco, Rossi ); Session session = getsessionfactory().opensession(); Transaction tx = session.begintransaction(); session.save( user ); tx.commit(); //Si termina la prima transazione ma non si chiude la sessione //Si riapre poi una nuova transazione. //In realta' non e' necessario aprire la sessione prima delle modifiche all'oggetto. tx = session.begintransaction(); user.setname( Gianni ); tx.commit(); session.close(); Come si vede dall'esempio, se un oggetto rimane attaccato alla sessione (persistent) viene automaticamente sincronizzato col database ogni volta che si esegue un commit di una transazione. Hibernate mette a disposizione un'insieme di metodi per gestire lo stato persistente degli oggetti: è possibile attaccare un oggetto detached alla sessione, obbligando a sincronizzare eventualmente le modifiche, oppure rileggendo lo stato attuale da database. È possibile eliminare un oggetto dalla sessione senza eliminarlo dal database. È possibile caricare un oggetto richiedendo un lock di sola lettura o lettura-scrittura. 5.5 Persistenza transitiva Un'altra caratteristica interessante di Hibernate è quella della persistenza transitiva. La persistenza transitiva permette di rendere persistenti non solo gli oggetti che manualmente

28 Hibernate 28 attacchiamo alla sessione, ma pure tutti gli oggetti che in qualche modo sono raggiungibili da esso. In pratica possiamo decidere se, una volta reso persistente un oggetto, tutti gli oggetti referenziati dall'oggetto debbano essere persistenti, anche ricorsivamente. Questo meccanismo risulta molto utile poiché lo sviluppatore non deve più preoccuparsi di salvare ogni oggetto o eseguire i singoli update. Quando un'applicazione interagisce con un oggetto, può modificarlo, aggiungere elementi ad una sua proprietà di tipo collezione o cambiare il riferimento ad un entità, modificare lo stato o cambiare uno qualsiasi di questi oggetti correlati; quando verrà eseguito il commit della transazione, ogni modifica, inserimento o cancellazione a tutto il grafo di elementi sarà eseguita in automatico. La politica di persistenza transitiva (indicata in Hibernate col termine cascade) può essere specificata per ogni attributo della classe all'interno del file di mapping, dando allo sviluppatore un controllo fine sul modo con cui essa opera. Listato 5.3: Department.hbm.xml con l'attributo cascade <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" " <hibernate-mapping package="domain"> <class name="department" table="departments" > <id name="id" column="id" type="long"> <generator class="native" /> </id> <property name="name" column="name" type="string" /> <property name="depcode" column="dep_code" type="integer" /> <set name="users" table="users" lazy="true" inverse="true" cascade="save-update"> <key column="dep" not-null="true" /> <one-to-many class="user" /> </set> </class> </hibernate-mapping> L'attributo cascade= save-update permette di rendere persistenti tutte le aggiunte di elementi o le modifiche agli elementi della collezione.

29 6 Interrogazioni con Hibernate

30 Hibernate Recuperare oggetti per Id Come è già stato mostrato nei precedenti esempi Hibernate è in grado di recuperare oggetti da un database utilizzando semplici metodi di Session. Se vogliamo ottenere un'istanza persistente dato l'id del record è sufficiente utilizzare il metodo get: Listato 6.1: Recuperare un oggetto per id Session session = getsessionprovider().opensession(); Transaction tx = session.begintransaction(); User user = session.get( User.class, new Long( 12 ) ); tx.commit(); session.close(); 6.2 Interrogazioni con HQL Ovviamente il metodo mostrato al paragrafo precedente non è sufficiente. Hibernate mette a disposizione un vero e proprio linguaggio simil-sql, l'hql (Hibernate Query Language), che permette di interrogare il database utilizzando le classi Java e le proprietà della classe al posto delle tabelle e dei campi. L'esempio che segue mostra come creare un'interrogazione che cerca tra gli utenti quelli che hanno nome Mario : Listato 6.2: HQL per un interrogazione semplice Session session = getsessionprovider().opensession(); Transaction tx = session.begintransaction(); Query q = session.createquery( select u from User u where u.name = :fname ); q.setstring( fname, Mario ); List<User> users = q.list(); tx.commit(); session.close(); Si nota subito l'assoluta somiglianza con SQL, ma User e u.name rappresentano la classe User e il suo attributo name. Un aspetto interessante che rende più semplice HQL dell'sql standard è il fatto che le join con Hibernate sono implicitamente scritte nel mapping e nel modello di dominio. Normalmente, a differenza di SQL, con HQL non è necessario scrivere join per ottenere le entità associate ad User. Se ad esempio riprendiamo la classe User del Listato 4.2: La classe User modificata, non è necessario mettere in join la classe Department nella query di interrogazione scritta sopra. Infatti, a seconda della politica di cascade dell'associazione, nel momento in cui viene inizializzato un oggetto di tipo User, l'associazione a Department viene o inizializzata o rimpiazzata con un proxy che inizializza l'associazione al suo primo accesso. Se invece abbiamo bisogno di eseguire un'interrogazione che ponga dei criteri anche sulla classe Department, è sufficiente includere nella where la proprietà di department deferenziandola col nome dell'attributo department:

31 31 Capitolo 6 Interrogazioni con Hibernate Listato 6.3: Query con join implicita Query q = session.createquery( select u from User u where u.name=:fusername and u.department.name=:fdepname ); q.setstring( fusername, Mario ); q.setstring( fdepname, My department ); List<User> users = q.list(); Da notare che nella query non è stata scritta alcuna join. Hibernate sa che per ottenere una where sul nome del dipartimento deve eseguire una join SQL, ma questo rimane trasparente allo sviluppatore che ha scritto l'hql. Con HQL è anche possibile eseguire join esplicite e select multiple. Anche in questo caso la sintassi HQL è molto più semplice e compatta di SQL: Listato 6.4: Query con join esplicita Query q = session.createquery( select u, d from User u, u.department d + where u.name=:fusername and d.name=:fdepname ); q.setstring( fusername, Mario ); q.setstring( fdepname, My department ); List<User> users = q.list(); In questo caso la join è ottenuta da u.department grazie al fatto che Hibernate conosce già l'associazione, grazie alla presenza dei file di mapping. Gli elementi della lista risultante da questa interrogazione sono array bidimensionali contenenti le istanze dei due oggetti richiesti.

32 7 Un esempio pratico

33 33 Capitolo 7 Un esempio pratico In questo capitolo viene presentato un esempio pratico di utilizzo di Hibernate. L'esempio è minimale, non si concentra assolutamente sulla presentazione dei dati o sulla loro immissione, bensì sull'utilizzo basilare di Hibernate. Per questo motivo, il database utilizzato per l'esempio è HSQLDB, un database leggero che può essere creato in memoria e che quindi non richiede alcuna installazione. Ovviamente per questo esempio può essere utilizzato un qualsiasi altro database supportato da Hibernate, modificando la configurazione della SessionFactory e aggiungendo la libreria-driver per l'accesso al particolare DB. L'esempio viene costruito facendo uso dell'ambiente di sviluppo open-source Eclipse ( 7.1 Installazione dei prerequisiti Java Nel sistema deve essere installata una versione della JDK di Java. Si consiglia l'ultima versione della Java 6. Per scaricare e installare una JDK consultare il seguente sito: Eclipse Eseguire il download dell'ultima versione di Eclipse dal sito facendo attenzione di prendere quella per il proprio sistema operativo (esistono versioni per Windows, Mac e Linux). Tra le versioni presenti è sufficiente scaricare Eclipse IDE for Java Developers. Scompattare l'archivio scaricato in una qualsiasi cartella. Lanciare Eclipse dall'eseguibile presente nella cartella scompattata Hibernate Scaricare l'ultima versione di Hibernate distribution dal sito (al tempo di questo documento è la versione 3.6.0). Scompattare l'archivio in una qualsiasi cartella HSQLDB Scaricare l'ultima versione del database dal sito Scompattare l'archivio in una qualsiasi cartella.

34 Hibernate Creazione di un nuovo progetto Da dentro Eclipse eseguire il comando File-New-Java project. Impostare Hibernate Test come nome del progetto e cliccare su Finish. Nella finestra Package Explorer che dovrebbe comparire sulla sinistra selezionare col destro il nome del progetto e aggiungere una nuova cartella chiamata lib tramite il comando New-Folder. Aprire un browser del file system, entrare nella cartella in cui è stato scompattato Hibernate, selezionare il file hibernate3.jar e copiarlo nella cartella lib del progetto appena creata (il copy-paste funziona tranquillamente tra browser ed Eclipse). Entrare nella cartella lib della distribuzione Hibernate, poi nella sottocartella required, selezionare tutti i file in essa contenuta e copiarli nella cartella lib del progetto. Entrare nella cartella lib della distribuzione Hibernate, poi nella sottocartella jpa della distribuzione Hibernate e copiare il file contenuto nella cartella lib del progetto. Entrare nella cartella dove è stato scompattato HSQLDB, entrare nella sottocartella lib e copiare il file hsqldb.jar nella cartella lib del progetto. Infine, selezionare tutti i file contenuti nella cartella lib del progetto, cliccare col destro e eseguire il comando Build path-add to build path.

35 35 Capitolo 7 Un esempio pratico Con questa procedura sono state inserite dentro il progetto tutte le librerie necessarie per utilizzare Hibernate e HSQLDB e il progetto è stato configurato per utilizzarle nel proprio class-path. 7.3 Creazione delle classi del dominio Cliccare col destro sulla cartella src del progetto, eseguire il comando New-Class e impostare la classe come nell'immagine che segue: Il nome del package è domain, il nome della classe è User. Il resto della finestra rimane come di default. Cliccando su Finish si ottiene un nuovo file java sotto source. Riempire la classe come segue. package domain; public class User { private Long id; private String name; private String lastname; private Department department; public User() {