Tecnologie Web T Metodologie di Progettazione della Persistenza: Approccio forza bruta, Pattern DAO, Framework ORM e Hibernate

Tecnologie Web T Metodologie di Progettazione della Persistenza: Approccio forza bruta, Pattern DAO, Framework ORM e Hibernate Home Page del corso: http://www-db.disi.unibo.it/courses/tw/ Versione elettronica: 4.02.MetodologieProgettazionePersistenza.pdf Versione elettronica: 4.02.MetodologieProgettazionePersistenza-2p.pdf 1

Gestione della persistenza Le nostre applicazioni sono sviluppate con linguaggi OO (lo stesso vale anche per i moderni sistemi informativi) mentre la persistenza dei dati è affidata ai DBMS relazionali OO: scalabilità e riusabilità RDBMS: affidabilità, efficienza, efficacia Esistono differenze significative tra queste due tecnologie: differenze tecnologiche differenze culturali Si parla di conflitto di impedenza 2

Conflitto di impedenza (1/4) Definito anche come disaccoppiamento di impedenza (o impedance mismatch) tra base di dati e linguaggio linguaggi: operazioni su singole variabili o oggetti SQL: operazioni su relazioni (insiemi di ennuple) Differenze di accesso ai dati e correlazione: linguaggio: dipende dal paradigma e dai tipi disponibili; ad esempio scansione di liste o navigazione tra oggetti SQL: join (ottimizzabile) 3

Conflitto di impedenza (2/4) Differenze sui tipi di dato primitivi: linguaggi: numeri, stringhe, booleani SQL: CHAR, VARCHAR, DATE,... Differenze sui costruttori di tipo: linguaggio: dipende dal paradigma SQL: relazioni e ennuple OID (trasparenti al programmatore) vs. chiavi primarie (visibili e manipolabili) Riferimenti vs. chiavi esterne Ereditarietà (senza controparte nel mondo relazionale) 4

Conflitto di impedenza (3/4) In generale, i dati risiedono nel database (DB) mentre la logica applicativa viene implementata da oggetti Dal modello concettuale si può derivare (una prima versione di) classi che implementano la logica applicativa (diciamo che queste classi implementano il modello di dominio, o più semplicemente il modello) classi facade che offrono le operazioni (metodi) dell applicazione schema relazionale per memorizzare i dati questa attività può essere fatta anche successivamente in alcuni casi (sistemi legacy) il database potrebbe esistere già e potrebbe non essere modificabile quindi tutte le attività di progetto sono condizionate da questo vincolo 5

Conflitto di impedenza (4/4) I dati sono memorizzati in maniera persistente nel DB A seconda del punto di vista (sviluppatore OO vs. DB Administrator - DBA) Gli oggetti in memoria possono essere visti come una copia di una porzione del database Il database può essere visto come un supporto su cui memorizzare in maniera persistente i dati del modello Il conflitto di impedenza investe anche aspetti "culturali" 6

Metodologie per la gestione della persistenza In generale possiamo pensare che le operazioni (metodi) degli oggetti facade caricano tuple dalla base di dati e le usano per creare gli oggetti del modello effettuano le operazioni della logica applicativa (es. evadi ordine) salvano in maniera persistente gli oggetti del modello nella base di dati L'interazione con il DB è una operazione critica: esistono diverse metodologie (di complessità crescente) per realizzare questa interazione forza bruta pattern DAO framework ORM (e in particolare per noi Hibernate) 7

Forza bruta È la tecnica più semplice per gestire la persistenza forte accoppiamento con la sorgente dati Consiste nello scrivere dentro le classi del modello un insieme di metodi che implementano le operazioni CRUD Operazioni CRUD Create: inserimento di una tupla (che rappresenta un oggetto) nel database (INSERT) Retrieve: ricerca di una tupla secondo un qualche criterio di ricerca (SELECT) Update: aggiornamento di una tupla nel database (UPDATE) Delete: eliminazione di una tupla nel database (DELETE) Ci possono essere diverse operazioni di Retrieve diversi criteri: per chiave vs. per attributo (es. ricerca cliente per codice, per nome, etc.) diversi risultati (un oggetto, una collezione di oggetti) a seconda del criterio 8

Forza bruta in sintesi (1/2) Per ogni classe MyC che rappresenta una entità del dominio, si definiscono: un metodo doretrievebykey(x key) che restituisce un oggetto istanza di MyC i cui dati sono letti dal database tipicamente da una tabella che è stata derivata dalla stessa classe del modello di dominio che ha dato origine a MyC recupera i dati per chiave un metodo saveorupdate( ) che salva i dati dell'oggetto corrente nel database il metodo esegue una istruzione SQL update o insert a seconda che l'oggetto corrente esista già o meno nel database 9

Forza bruta in sintesi (2/2) uno o più metodi doretrievebycond( ) che restituiscono una collezione di oggetti istanza della classe MyC che soddisfano una qualche condizione (basata sui parametri del metodo) un metodo dodelete( ) che cancella dal database i dati dell'oggetto corrente 10

Il pattern Data Access Object La soluzione Forza bruta non è particolarmente conveniente L'accoppiamento tra la sorgente dati e le classi del modello è molto forte Le classi del modello sono poco coese (responsabilità eterogenee) Molto difficile iniziare a sviluppare senza preoccuparsi di tanti (troppi!) dettagli e senza un ambiente operativo complesso (java + dbms) Una soluzione "naturale" è quella di affidare le responsabilità di interagire con il database ad opportune classi Questo è l'approccio suggerito dal pattern Data Access Object (DAO) 11

Il pattern DAO Un pattern è un modo di fare le cose che si è dimostrato efficace e che per questo si tende ad applicare di nuovo Il pattern DAO è uno degli standard J2EE design patterns ; rappresenta un possibile modo di separare: logica di business (es: Servlet, JSP, ) logica di persistenza (es: r/w su DB, ) Infatti, i componenti della logica di business non dovrebbero mai contenere codice che accede direttamente al database! scarsa manutenibilità sovrapposizione di responsabilità Solo gli oggetti previsti dal pattern DAO hanno il permesso di vedere il DB espongono metodi di accesso per tutti gli altri componenti 12

DAO: Caratteristiche principali (1/2) I valori scambiati tra DB e il resto dell applicazione sono racchiusi in oggetti detti Data Transfer Object (DTO): campi privati per contenere i dati da leggere/scrivere su db metodi getter e setter per accedere dall esterno a tali campi metodi di utilità (confronto, stampa, ) Le operazioni che coinvolgono tali oggetti sono raggruppati in interfacce che definiscono i Data Access Object (DAO) disponibili: metodi CRUD altri metodi 13

DAO: Caratteristiche principali (2/2) Le implementazioni di tali interfacce (spesso indicate come oggetti DAO, per brevità) permettono l effettivo accesso al database diverse implementazione possono permettere (e rendere uniforme) l'accesso a DB di diversi vendor anche se si fa uso di un solo database, tale separazione migliora comunque la divisione delle responsabilità tra le parti dell applicazione diventa facile migrare l applicazione su DB diversi Gli oggetti DAO non sono istanziati direttamente dai componenti, ma: possono essere ottenuti attraverso metodi factory 14

Pattern DAO con classi Factory Una unica factory astratta fornisce specifiche per le factory concrete espone un metodo creazionale parametrico per ottenere factory concrete Una factory concreta per ogni tipo di DB supportato permette di ottenere oggetti DAO appropriati al corrispondente tipo di DB può gestire aspetti quali ottenimento della connessione, autenticazione,... Un oggetto DTO per ogni tipo di entità che si vuole rappresentare Una interfaccia DAO per ogni oggetto DTO Una implementazione dell'interfaccia DAO di un DTO per ciascun DB supportato 15

Pattern DAO con classi Factory 16

Pattern DAO con classi Factory: Diagramma di sequenza 17

Pattern DAO: Struttura 18

Pattern DAO: Diagramma di sequenza 19

DAO in pratica Per ogni classe Entità del modello di dominio creiamo (in un opportuno package) una interfaccia DAOEntità con (le signature dei) metodi che realizzano le operazioni CRUD Queste interface sono implementate da classi (organizzate in opportuni package) questa scomposizione permette maggiore flessibilità 20

Caso di studio (UML) Prodotto CodiceProdotto Nome Descrizione Costo 1 * RigaOrdine * Quantità NumeroLinea 1 Ordine CodiceOrdine Data stato * 1 Cliente CodiceCliente Nome Indirizzo 21

Esempio: ProdottoDAO public interface ProdottoDAO { public List<Prodotto> doretrieveall() throws PersistenceException; public Prodotto doretrivebykey(string codice) throws PersistenceException; public void saveorupdate(prodotto prodotto) throws PersistenceException; public void delete(prodotto prodotto) throws PersistenceException; } // eventuali altri doretriveby... 22

Esempio: ProdottoDAOImpl public class ProdottoDAOImpl implements ProdottoDAO { public List<Prodotto> doretrieveall() throws PersistenceException { Connection connection = null; List<Prodotto> prodotti; try { } catch (SQLException sqle) { throw new PersistenceException(sqle); } finally { } return prodotti; } } 23

Interazione Facade-DAO: Esempio ProdottoDAO Facade ProdottoDB2DAO DB2 Prodotto 24

Mettiamo ordine al codice Abbiamo classi per il modello, classi per la persistenza, classi di utilità classi del modello nel package modello interfacce DAO nel package persistenza implementazioni (dbms dependant) dei DAO in package persistenza.db2 classi di utilità nel package util 25

Nota terminologica Le classi del modello implementano le entità del modello concettuale, ed è bene che rispettino le seguenti convenzioni: tutte le proprietà devono essere private per ogni proprietà: metodi setter e getter pubblici costruttore no-arg visibile Una classe che rispetta queste convenzioni viene chiamata java bean Rispetto al nostro caso di studio, le nostre classi Cliente, Prodotto, Ordine, RigaOrdine sono bean 26

Caso di studio package modello; import java.util.*; import persistenza.*; public class FacadeImpl implements Facade { private ClienteDAO clientedao;. public FacadeImpl() { clientedao = new ClienteDAOImpl(); } public void inserisciclientenellaanagrafica(cliente cliente) throws ClienteException { try { clientedao.saveorupdate(cliente); } catch (PersistenceException e) { throw new ClienteException("Exception in ClientiFacade while creating cliente."); } } public List<Cliente> anagraficaclienti(){ try { return clientedao.doretrieveclienteall(); } catch (PersistenceException e) { throw new ClienteException("Exception in ClientiFacade while retrieving cliente.", e); } } } public Cliente trovaclientepercodice(string codicecliente){ try { return clientedao.doretrieveclientebycodice(codicecliente); } catch (PersistenceException e) { throw new ClienteException("Exception in ClientiFacade while retrieving cliente"+ codicecliente +, e); } } ORM e Hibernate 27

Soluzioni al conflitto di impedenza Analizziamo ora i principali problemi dovuti al conflitto di impedenza e ne presentiamo le soluzioni A scopo didattico lavoriamo su DAO, ma le considerazioni che facciamo seguendo questa soluzione hanno validità generale!! Al termine del trattamento generale delle problematiche relative al conflitto di impedenza, concluderemo la gestione della persistenza illustrando la metodologia Object Relational Mapping (ORM) e una sua diretta implementazione, ovvero il framework Hibernate 28

Risolvere il conflitto di impedenza Nel modello OO, le relazioni tra oggetti sono realizzate con riferimenti, mentre nel modello relazionale sono realizzate con i valori Vediamo problemi e soluzioni relativamente a: Retrieve: dal DB agli oggetti (ricostruzione degli oggetti a partire da dati persistenti) Create: dagli oggetti al DB (memorizzazione persistente degli oggetti nel DB) 29

Retrieve: Ricostruzione degli oggetti dal DB Il problema principale nel ricostruire oggetti a partire dalla base di dati consiste nel ricostruire i riferimenti Forze in gioco chiavi esterne contro riferimenti join (operazione "non direzionale") contro navigazioni 30

Caso di studio Prodotto CodiceProdotto Nome Descrizione Costo 1 RigaOrdine * * Quantità NumeroLinea 1 Ordine CodiceOrdine Data stato * 1 Cliente CodiceCliente Nome Indirizzo 31

Ricostruzione degli oggetti dal DB Consideriamo la ricostruzione di un oggetto Ordine, ad esempio, per definire il metodo Ordine doretrieveordinebykey(string codice) nella classe Ordine: una collezione di riferimenti a oggetti RigaOrdine ogni riga ordine ha un riferimento ad un oggetto Prodotto un riferimento ad un oggetto della classe Cliente nel database: tabella ORDINI (ha una foreign key (FK) con CLIENTI) tabella RIGHEORDINE (FK con ORDINI, FK con PRODOTTI) tabella CLIENTI Per ricostruire un oggetto Ordine "completo" devo ricostruire la collezione di oggetti RigaOrdine e l'oggetto Cliente (e anche questi oggetti devono essere "completi"?!) 32

Ricostruzione degli oggetti dal DB Per ora, a fini didattici, non preoccupiamoci del riferimento Cliente: successivamente ci preoccupiamo anche di questo Come ricostruiamo l'oggetto Ordine? eseguo un join tra le tabelle ORDINI e RIGHEORDINE itero sul ResultSet e costruisco i vari oggetti Ordine e RigaOrdine opportunamente collegati 33

Nota Eseguo un join tra le tabelle ORDINI e RIGHEORDINE Che join usiamo? è possibile che nella tabella ORDINI ci siano tuple per le quali non ci sono righe nella tabella RIGHE_ORDINE? se la risposta è SI, allora devo usare un outer join 34

Un inciso Potrebbe sembrare più semplice evitare di effettuare un join, usando due SELECT e gestendone i risultati nel codice Java: cerco nella tabella ORDINI del database l'ordine con l'id richiesto e costruisco un oggetto Ordine cerco nella tabella RIGHEORDINE del database le tuple che hanno come chiave esterna l'id dell'oggetto Ordine del punto precedente e con esse costruisco una collezione di oggetti RigaOrdine aggiungo la collezione di righe ordine all'oggetto Ordine Commenti: (apparentemente) il codice per costruire l'oggetto Ordine è più semplice (ma se sapete usare le collezioni il problema non si pone più di tanto ) ma i DBMS sono ottimizzati per effettuare efficientemente join! 35

Ricostruzione degli oggetti dal DB Ma che cosa è un "oggetto completo"? con un modello di dominio complesso questa strategia può portarci a caricare una rete molto vasta di oggetti esempio: Cliente Ordine RigaOrdine Prodotto Fornitore Fino a quando devo costruire oggetti "inseguendo i riferimenti? 36

Ricostruzione degli oggetti dal DB Possiamo dare una risposta a queste domande analizzando i casi d'uso e il modello del dominio In particolare l'inseguimento dei riferimenti tra oggetti è guidato dalle operazioni offerte dal sistema Nel progettare le classi, i riferimenti vanno messi considerando la direzione in cui le corrispondenti associazioni sono navigate dalle operazioni del sistema! questo aspetto non ha rilevanza nella progettazione del database, perché i riferimenti sono implementati tramite valori e l'operatore di join non è direzionale 37

Ricostruzione degli oggetti dal DB E quando non ha senso costruire un oggetto completo, come mi comporto? i metodi che richiedono l'inseguimento di un riferimento, se invocati devono restituire l'oggetto corretto! In questo caso ricorriamo ad una tecnica, detta Caricamento Pigro, implementata tramite l'applicazione del Pattern Proxy 38

Lazy Load (caricamento pigro) Consideriamo la classe Cliente: l'associazione con l'ordine è bidirezionale Tuttavia non è ragionevole pensare che per caricare i dati di un cliente si debba ricostruire l'intera rete di oggetti (fino a Prodotto!?) Possiamo pensare che gli ordini associati al cliente possano essere caricati solo quando richiesti: quando invochiamo il metodo getordini() su un oggetto Cliente Questa strategia si chiama Lazy Load (caricamento pigro) 39

Lazy Load (caricamento pigro) In pratica quello che vogliamo fare è caricare i dati solo quando questi sono effettivamente richiesti Vediamo come dovrebbe agire il metodo getordini() della classe Cliente seguendo questa strategia quando invocato per la prima volta, il metodo getordini() esegue la query per costruire gli oggetti Ordine associati al cliente, aggiunge i riferimenti a questi oggetti nella collezione dell'oggetto Cliente, e restituisce la collezione È importante osservare che se il metodo non viene mai invocato, il costo di caricare i dati relativi agli ordini non viene mai pagato Se decidiamo di implementare questa strategia nella classe Cliente mettiamo codice di gestione della persistenza in una classe del dominio se in futuro vogliamo cambiare strategia? Per implementare bene la strategia Lazy Load senza ridurre la coesione nella classe del modello è utile fare riferimento al pattern Proxy 40

Lazy Load e classi proxy Le classi xxxdaoimpl non restituiscono un bean completo ma un proxy Il proxy ha il compito di gestire il caricamento degli oggetti collegati Il proxy deve contenere tutte le informazioni necessarie per effettuare il caricamento lazy Gli oggetti collegati vengono caricati solo su richiesta Il proxy simula il comportamento del bean 41

Lazy Load: Dettagli Quando le classi xxxdaoimpl ricevono una richiesta viene eseguita una query sul DB, istanziato e restituito un oggetto del tipo richiesto L oggetto istanziato non è di tipo xxxbean, ma xxxproxy La classe xxxproxy estende la corrispondente xxxbean e riscrive i metodi che devono implementare le operazioni onerose Vediamo un esempio 42

Lazy Load: Implementazione con proxy public class Cliente { private int codicecliente; private List<Ordine> ordini; public List<Ordine> getordini() { return this.ordini; }... } public class ClienteProxy extends Cliente { public List<Ordine> getordini() { List<Ordine> listaordini = null; try { OrdineDAO daoordine = new OrdineDAOImpl(); listaordini = daoordine.doretrievebycliente(this.getcodice()); this.setordini(listaordini); } catch (PersistenceException e) { throw new UnChechedPersistenceException(e.getMessage()); } return listaordini; } } 43

Lazy Load: Implementazione con proxy (e caching) public class Cliente { private int codicecliente; private List<Ordine> ordini; public List<Ordine> getordini() { return this.ordini; }... } public class ClienteProxy extends Cliente { private boolean caricato = false; public List<Ordine> getordini() { try { if (!this.caricato) { OrdineDAO dao = new OrdineDAOImpl(); this.setordini(dao.doretrievebycliente(this.getcodice())); this.caricato = true; } } catch (PersistenceException e) { throw new UnChechedPersistenceException(e.getMessage()); } return super.getordini(); } } 44

Lazy Load: Osservazioni Quando uso il "caricamento pigro"? Dipende dai casi d uso definiti in fase di progettazione Ordine e RigaOrdine Esistono casi d uso che prevedono l uso dell intestazione dell ordine ma non del dettaglio delle righe? RigaOrdine e Prodotto etc. Esistono casi d uso che prevedono l uso di una o più riga senza il dettaglio del prodotto? 45

Lazy Load: Organizzazione del codice Organizzazione del codice: I Proxy appartengono al package della persistenza (in particolare, al package con le implementazioni dei DAO) 46

Ricostruzione degli oggetti dal DB Concludiamo ora la scrittura del codice per la classe OrdineDAO In particolare supponiamo di voler effettuare un caricamento pigro del cliente associato all'ordine public public class class OrdineProxy extends Ordine Ordine { { private Cliente cliente; public public Cliente Cliente getcliente() throws throws DAOException { { if (cliente==null) { String String query = query "select = "select * from * clienti from clienti " + " + "where clienti.codice "where clienti.codice =?"; =?"; }} return cliente; } } C'è un problema: non abbiamo il codice cliente! Coerentemente con l'approccio OO nella classe abbiamo un riferimento ad un oggetto Cliente Questo dato è presente nella tabella ORDINI (chiave esterna), e quando abbiamo caricato l'ordine questo valore non è stato salvato in nessuna variabile!! 47

Ricostruzione degli oggetti dal DB Siamo costretti ad eseguire un join (ci sarebbe bastata una selezione) public class OrdineProxy extends Ordine { public private class Cliente OrdineProxy cliente; extends Ordine { private Cliente cliente; public Cliente getcliente() { public if (cliente==null) Cliente getcliente() { { if String (cliente==null) query = "select { * from ordini join clienti on " + String "ordini.idcliente query = "select = clienti.id * from ordini where join ordini.id clienti =?"; on ordini.id = clienti.idordine" // codice per l'esecuzione where ordini.id della = query?"; // codice per l'esecuzione della query // con i dati ritornati restituiti viene costruito l'oggetto l'obj Cliente } return cliente; } } } Il problema sussiste anche nella classe Cliente? Perchè? 48

Ricostruzione degli oggetti dal DB Il problema sorge quando navighiamo una relationship uno-a-molti o uno-a-uno seguendo il vincolo di integrità referenziale (la chiave esterna) Per risolvere questo problema dobbiamo effettuare un join (al posto di una semplice selezione) 49

Ricostruzione degli oggetti dal DB Possiamo sintetizzare il processo di ricostruzione degli oggetti dal DB come segue: in base ai casi d'uso (e a una stima della frequenza delle corrispondenti operazioni) decidiamo quando conviene seguire una strategia Lazy Load per le classi con associazioni per le quali è stata scelta la strategia Lazy Load applichiamo il pattern Proxy per le classi con associazioni per le quali non conviene applicare la strategia Lazy Load ricostruiamo la rete (parziale) di oggetti con i risultati di un join In fase di progettazione conviene quindi arricchire il class diagram con annotazioni sulle associazioni che indicano la strategia di caricamento ("fetch") dei dati: pigro (Lazy Load) vs. immediato (Eager) 50

Caso di studio Prodotto CodiceProdotto Nome Descrizione Costo 1 RigaOrdine * * Quantità NumeroLinea fetch: lazy-load fetch: eager fetch: eager 1 Ordine CodiceOrdine Data stato * 1 Cliente CodiceCliente Nome Indirizzo fetch: lazy-load 51

Risolvere il conflitto di impedenza Nel modello OO, le relazioni tra oggetti sono realizzate con riferimenti, mentre nel modello relazionale sono realizzate con i valori Vediamo problemi e soluzioni relativamente a: Retrieve: dal DB agli oggetti (ricostruzione degli oggetti a partire da dati persistenti) Create: dagli oggetti al DB (memorizzazione persistente degli oggetti nel DB) 52

Create: Rendere persistenti gli oggetti L'operazione di CREATE ha lo scopo di rendere persistenti gli oggetti della applicazione Problemi persistenza dei riferimenti propagazione degli aggiornamenti 53

Persistenza dei riferimenti Come rendiamo persistenti i riferimenti? se il dominio offre identificatori naturali per tutte le entità il problema è limitato (ma potremmo fare considerazioni su prestazioni e portabilità) se non tutte le classi hanno identificatori naturali ("semplici") è utile introdurre chiavi surrogate In generale è sconveniente usare un approccio ibrido (chiavi surrogate e identificatori naturali) Di conseguenza, quando possibile*, è consigliato usare sempre chiavi surrogate tutte le tabelle corrispondenti a entità del dominio hanno una chiave id di tipo intero tutte le classi hanno una variabile di istanza id di tipo intero * Potrebbe non essere possibile nel caso di applicazioni costruite su DB già esistenti 54

Persistenza dei riferimenti Chiavi surrogate la chiave può essere vista come una rappresentazione persistente dell'oid in parte cerchiamo di avvicinare i due mondi (relazionale ed oggetti) senza stravolgerli, armonizzando le differenze Questa soluzione offre vantaggi in termini di prestazioni (usando come chiavi degli interi) portabilità ed evoluzione (gli identificatori naturali possono cambiare nel tempo*) *Esempio: è allo studio una revisione del codice fiscale 55

Persistenza dei riferimenti Che cosa deve fare una operazione di Create se l'oggetto non esiste nel DB l'operazione di Create deve eseguire una insert nel DB dei dati gestiti da un oggetto del modello Se nel DB usiamo chiavi surrogate, come le gestiamo? è opportuno avere una rappresentazione della chiave anche nel modello ad oggetti quindi ad ogni entità associamo esplicitamente una variabile di istanza id (di tipo int) 56

Persistenza dei riferimenti Chi ci dà il valore di una chiave surrogata? la chiave viene creata al momento dell'inserimento di un oggetto nel DB Diverse soluzioni: soluzione naive: chiedo al DB il valore massimo, lo incremento ed eseguo l'inserimento usando tale valore uso campi auto-incrementanti: occorre aggiornare il valore della variabile id nell'oggetto, ovvero dopo l'inserimento, dobbiamo interrogare il DB per riottenere tale valore uso una sequenza SQL che interrogo per farmi dare un nuovo id prima di ogni inserimento efficiente (il DBMS offre anche funzionalità di caching) semplice da implementare qualche limite di portabilità (nonostante le sequenze siano standard SQL, i vari DBMS differiscono un po' nell'uso di questo costrutto) 57

Persistenza dei riferimenti Affidiamo la responsabilità della gestione degli id ad una classe opportuna, che chiamiamo IdBroker Al solito, per favorire la portabilità possiamo definire una interfaccia IdBroker, le cui implementazioni sono DBMS-dependant 58

IdBroker: Esempio package persistenza.db2; import java.sql.*; import persistenza.*; public class IdBrokerDB2 implements IdBroker { public int newid() throws PersistenceException { int newid = -1; DataSource ds = new DataSource(); ResultSet result = null; PreparedStatement statement = null; Connection connection = null; try { connection = ds.getconnection(); String sqlquery = "SELECT(NEXTVAL FOR sequenza_id) INTO newid"; statement = connection.preparestatement(sqlquery); result = statement.executequery(); if (result.next()) newid = result.getint("newid"); else throw new PersistenceException("invalid id"); } catch(sqlexception e) { throw new PersistenceException(e.getMessage()); } finally { try { if (statement!= null) statement.close(); if (connection!= null) connection.close(); } catch (SQLException e) { throw new PersistenceException(e.getMessage()); } } return newid; } } 59

Persistenza dei riferimenti: Esempio public class ProdottoDAODB2 { private void insert(prodotto prodotto, Connection connection) throws PersistenceException { PreparedStatement statement = null; IdBroker idbroker = new IdBrokerDB2(); try { prodotto.setid(idbroker.newid()); String insert = "insert into prodotti(codice_prodotto, nome, descrizione, disponibilita, prezzo, id) values (?,?,?,?,?,?)"; statement = connection.preparestatement(insert); statement.setint(1, prodotto.getcodiceprodotto()); statement.setstring(2, prodotto.getnome()); statement.setstring(3, prodotto.getdescrizione()); statement.setint(4, prodotto.getdisponibilita()); statement.setint(5, prodotto.getprezzo()); statement.setint(6, prodotto.getid()); statement.executeupdate(); } catch (SQLException e) { throw new PersistenceException(e.getMessage()); } finally { try { if (statement!= null) statement.close(); if (connection!= null) connection.close(); } catch (SQLException e) { throw new PersistenceException(e.getMessage()); } } } } 60

Sequenze SQL Statement SQL (DB2) per la creazione della sequenza: CREATE SEQUENCE sequenza_id AS INTEGER START WITH 1 INCREMENT BY 1 MINVALUE 0 MAXVALUE 9999999 NO CYCLE; 61

Propagazione degli aggiornamenti Quando effettuiamo una operazione di create (ma analogamente update o delete) propaghiamo gli aggiornamenti a tutta la rete di oggetti? Ad esempio, consideriamo la classe Ordine: quando salviamo i dati di un ordine, salviamo anche i dati di tutti gli oggetti RigaOrdine e Cliente ad esso associato? Anche in questo caso dipende dai casi d'uso 62

Progettazione della persistenza Facendo riferimento al class diagram, su tutte le associazioni indichiamo: la cardinalità il verso secondo cui l'applicazione naviga la associazione la strategia di fetch: Lazy Load vs. Eager (associata al verso) la strategia di propagazione degli aggiornamenti: Cascade vs. No cascade (associata al verso) 63

Caso di studio Prodotto CodiceProdotto Nome Descrizione Costo 1 fetch: lazy-load cascade: none RigaOrdine * * Quantità NumeroLinea fetch: eager cascade: persist, delete 1 fetch: eager cascade: none Ordine CodiceOrdine Data stato * 1 Cliente CodiceCliente Nome Indirizzo fetch: lazy-load cascade: none 64

Object Relational Mapping È tempo di riprendere e concludere il trattamento delle metodologie alternative a forza burta e DAO per la realizzazione del layer di persistenza, ovvero di trattare la tecnica Object Relational Mapping (ORM, O/RM oppure O/R mapping) Aumenta il livello di astrazione (semplicità di utilizzo per lo sviluppatore e diminuzione della quantità di codice che occorre scrivere) Aumenta la complessità (diminuzione delle performance) ORM è la persistenza automatica (e trasparente) di oggetti di applicazioni Java in tabelle di un DB relazionale, basata su metadati che descrivono il mapping tra oggetti e DB 65

ORM in sintesi (1/3) Lavora trasformando (in modo reversibile) i dati da una rappresentazione all altra; ciò implica alcune penalizzazioni in termini di performance tuttavia se ORM è implementato come middleware esistono diverse opportunità di ottimizzazione non possibili per un livello di persistenza hand-coded (à la JDBC) La fornitura e la gestione dei metadati che governano la trasformazione aggiungono overead al tempo di sviluppo tuttavia tale costo è inferiore o equivalente al costo che comporta il mantenimento di una soluzione hand-coded 66

ORM in sintesi (2/3) Una soluzione ORM consiste di quattro componenti: Una API per eseguire le operazioni CRUD sugli oggetti delle classi del modello Un linguaggio o una API per specificare query che fanno riferimento alle classi e alle proprietà delle classi Uno strumento per la specifica del mapping mediante metadata Una tecnica per l implementazione di ORM per interagire con oggetti transazionali al fine di eseguire funzioni di ottimizzazione quali, ad esempio, lazy load fetching e dirty checking 67

ORM in sintesi (3/3) Usiamo il termine full ORM per includere ogni livello di persistenza in cui SQL è automaticamente generato da una descrizione basata su metadati L applicazione interagisce con le API ORM e le classi del modello di dominio ed astrae dal livello SQL/JDBC sottostante Supporta object modeling sofisticati, quali composizione, ereditarietà, polimorfismo e persistenza attraverso raggiungibilità Un certo numero di tool commerciali e open source Java ORM hanno raggiunto questo livello di qualità Hibernate è un tool full ORM l API di Hibernate è nativa e progetta dagli sviluppatori Hibernate 68

Perché ORM e Hibernate? Tra i benefici di ORM e Hibernate Produttività: il codice dedicato alla gestione della persistenza di una applicazione Java è il più tedioso ; Hibernate elimina la maggior parte di questo duro lavoro permettendo di concentrare l attenzione su problemi di businnes logic Manutenibilità: poche linee di codice rendono il sistema più comprensibile perché esso enfatizza aspetti di businnes logic rispetto a dettagli implementativi; più importante, un sistema con meno linee di codice è più facile per il refactor Performance: una comune affermazione è che la persistenza hand-coded è sempre più performante rispetto a quella automatizzata; occorre però considerare anche aspetti di tempo e budget per la realizzazione della stessa Indipendenza dal vendor: ORM astrae una applicazione dal DB sottostante e dal dialetto SQL; se un tool ORM supporta un certo numero di DB (e la maggior parte lo fa) ciò conferisce portabilità alla applicazioni 69

Perché Hibernate e non DAO? Per lo sviluppatore la metodologia DAO può risultare onerosa (e noiosa ), in termini di scrittura di codice, e dipendente dal data source Inoltre persistenza e transazionalità sono gestite a livello di programmazione La metodologia Hibernate rappresenta una soluzione standard per riuscire a implementare persistenza e transazionalità velocemente e senza preoccuparsi dei dettagli del data source sottostante; esempio: Session session = HibernateUtil.getSessionFactory().openSession(); User user = new User("pippo"); String userid = (String) session.save(user); 70

Il framework Hibernate Rappresenta lo standard risolutivo per il mapping object/relational automatico tra oggetti Java e relazioni del DB Tale mapping si può realizzare per mezzo di descrittori XML specifici di Hibernate (soluzione di riferimento per noi) o, in alterantiva, di annotazioni Java conformi allo standard JPA Il framework Hibernate si appoggia e sfrutta le tecnologie SQL e JDBC ecco perché è stato coisì importante apprendere prima JDBC! 71

Un po di storia Il progetto relativo a Hibernate è stato promosso nel 2001 da Gavin King come alternativa all uso di entity bean à la EJB2 scopo principale quello di offrire migliori capacità nella gestione della persistenza semplificando tutte le complessità All inizio del 2003, il gruppo di sviluppo Hibernate ha avviato la realizzazione della release Hibernate 2 che offre miglioramenti significativi rispetto alla prima versione Dal 2010 la versione di riferimento è Hibernate 3.x Hibernate 3 (dalla versione 3.5.0 in su) rappresenta l implementazione certificata (standard) delle specifiche API Java Persistence, versione 2.0 Ultima versione (febbraio 2017) Hibernate 5.2.10 72

Hibernate Core Anche noto come Hibernate o Hibernate 3.x Software open source e free, distribuito sotto licenza GNU Libreria ORM per Java: servizio di base per la gestione della persistenza in applicazioni Java fornisce un framework per mappare un modello di dominio object-oriented su di una base di dati relazionale caratteristica primaria: mapping da classi Java a tabelle di una base di dati (e mapping da tipi di dati Java a tipi di dati SQL) inoltre, fornisce l abilità di interrogare la basi di dati 73

Hibernate Core Il codice della applicazione usa le API di Hibernate per gestire la persistenza I mapping tra classi Java e tabelle relazionali sono specificati in appositi file XML In linea di principio, lo sviluppatore è esonerato da: richieste di esecuzione di chiamate SQL gestione manuale dei risultati di chiamate SQL e loro eventuale conversione in oggetti L'applicazione rimane portabile in tutti i sistemi di gestione supportati, con pochissimo overhead Può essere usato in maniera indipendente dal tipo di applicazione, di piattaforma e di ambiente runtime, con tutti i JDK 74

Architettura Hibernate L architettura completa di Hibernate astrae dalle API JDBC/JTA sottostanti livello di applicazione può essere trasparente a questi dettagli Architettura di alto livello Architettura completa 75

Principali oggetti dell API Hibernate* SessionFactory Session Persistent Objects Transient and Detached Object Transaction N.B. Per ora ci basta pensare a una transazione come a una sequenza di operazioni che può concludersi con un successo o un insuccesso (unità atomica di elaborazione) ; affronteremo in modo approfondito la gestione delle transazioni a breve Connection Provider Transaction Factory * http://docs.jboss.org/hibernate/core/3.5/api/ 76

SessionFactory Classe org.hibernate.sessionfactory Factory per oggetti Session e cliente di ConnectionProvider Una factory per ogni DB Può mantenere una cache opzionale di secondo livello con dati riusabili in diverse transazioni 77

Session Classe org.hibernate.session Rappresenta un contesto di persistenza (wrapper a JDBC Connection) e la sua vita è delimitata dall inizio e dalla fine di una transazione logica Gestisce le operazioni del ciclo di vita degli oggetti persistenti Fa da factory per oggetti Transaction Mantiene una cache (non modificabile) di primo livello derivante dal mapping con il DB che viene utilizzata durante la navigazione degli oggetti 78

Oggetti persistent Oggetti single-threaded che contengono lo stato persistente e la logica di business Possono essere normali JavaBean devono essere associati esattamente a un oggetto Session Modifiche fatte sugli oggetti persistenti sono automaticamente propagate sulle tabelle DB (al loro commitment ) Appena si chiude la sessione, gli stessi oggetti diventano detached e possono essere usati liberamente 79

Oggetti transient e detached Istanze di classi persistenti che non sono correntemente associati a nessuna Session Possono essere stati istanziati dalla applicazione e non essere ancora diventati persistenti, oppure derivare da una Session chiusa Modifiche fatte su questi oggetti non si riflettono sul DB Operazioni di persist o merge per farli tornare persistenti (con modifiche correlate alle tabelle del DB) 80

Transaction Classe org.hibernate.transaction Oggetto single-threaded usato dalla applicazione per specificare unità atomiche di lavoro Permette di astrarre dai dettagli dei sottostanti meccanismi transazionali (JDBC, JTA, ) Un oggetto Session può essere coinvolto in diverse Transaction La demarcazione delle transazioni non è opzionale: indipendentemente dall utilizzare le API JDBC sottostanti o Transaction, deve comunque essere sempre specificata in modo esplicito 81

ConnectionProvider Classe org.hibernate.connection.connectionprovider Factory per un pool di connessioni JDBC. Astrae la applicazione dal Data Source o dal DriverManager sottostante Non è esposta alla applicazione ma può essere estesa e/o implementata dallo sviluppatore 82

TransactionFactory Classe org.hibernate.transactionfactory Factory per oggetti Transaction Non è esposta alla applicazione ma può essere estesa e/o implementata dallo sviluppatore 83

Stato degli oggetti persistenti Una istanza di una classe persistente può assumere in ogni istante uno fra tre stati possibili, definiti all interno di un contesto di persistenza Transient non appartenente a un contesto di persistenza Persistent appartenente a un contesto di persistenza Detached usualmente appartenente a un contesto di persistenza ma non in questo momento 84

Stato transient Istanza mai associata a una sessione (contesto di persistenza) Non ha identità di persistenza (valore associato alla primary key) Non ha righe corrispondenti nel DB 85

Stato persistent Istanza correntemente associata con una sessione (contesto di persistenza) Ha una identità di persistenza (valore associato alla primary key) e usualmente una riga corrispondente in una tabella DB Ad es. quando un oggetto viene creato in una sessione o un oggetto transient viene fatto diventare persistente 86

Stato detached Istanza che è stata associata a un contesto di persistenza in passato, ma quella sessione è stata chiusa oppure l istanza è stata trasferita tramite serializzazione a un altro processo Ha una identità di persistenza (valore associato alla primary key) e possibilmente una riga corrispondente in una tabella DB Ad es. quando un oggetto deve essere inviato ad un altro processo, che lo utilizzerà senza necessità di avere un contesto di persistenza associato 87

Il ciclo di vita degli oggetti persistenti Una applicazione orientata agli oggetti che fa uso di un meccanismo di persistenza deve interagire con il servizio di persistenza ogni volta che ha bisogno di propagare lo stato di un oggetto in memoria sulla base di dati Lo stato di un oggetto che appartiene ad una classe persistente cambia a seconda dell'operazione del servizio di persistenza che viene invocata 88

Transizioni di stato Oggetti Transient possono diventare persistenti tramite chiamate ai metodi save(), persist()o saveorupdate(), ovviamente dell oggetto Session associato Ogni istanza di oggetto persistente restituita da get()o load() è Persistent Oggetti Persistent possono diventare transienti tramite l invocazione di delete() Oggetti Persistent possono diventare staccati mediante l invocazione di evict(), clear()e close() Oggetti Detached possono diventare persistenti tramite chiamate ai metodi update(), saveorupdate() e merge()(con istanziazione di un nuovo oggetto persistente) 89

Hibernate Query Language Hibernate fornisce un linguaggio di interrogazione ispirato a SQL chiamato Hibernate Query Language (HQL) Permette la scrittura di query SQL-like definite sui data object Hibernate; esempi: Update a stock name to DIALOG1 where stock code is 7277 Query query = session.createquery("update Stock set stockname = :stockname" + " where stockcode = :stockcode"); query.setparameter("stockname", "DIALOG1"); query.setparameter("stockcode", "7277"); int result = query.executeupdate(); Delete a stock where stock code is 7277 Query query = session.createquery("delete Stock where stockcode = '7277'"); int result = query.executeupdate(); Sono inoltre supportate Criteria Queries come alternativa Object Oriented a HQL 90

Hibernate: Strategie di fetching Una strategia di fetching determina come e quando i dati vengono effettivamente caricati dal DB per una applicazione che usa gli oggetti di persistenza associati La strategia adottata ha ovviamente impatto sulle performance ottenibili ; di solito dichiarata in un file di mapping Modalità di fetching: FetchMode.DEFAULT (configurazione del mapping file) FetchMode.JOIN (Hibernate recupera i dati associati, anche collezioni, utilizzando un join all interno della stessa select) FetchMode.SELECT (Hibernate effettua una seconda select separata per recuperare le entity o collection associate) N.B. Il caricamento pigro (lazy fetching) è il default per SELECT: la seconda select viene eseguita solo quando l applicazione accede veramente ai dati associati 91

Hibernate: Strategie di caching Utilizzato per motivi di performance Idea di base: Rendere l accesso al DB necessario solo quando si devono reperire dati non sono già disponibili sulla cache La applicazione può avere bisogno di svuotare (invalidare) la cache se il DB viene aggiornato o se non è possibile sapere se la cache mantiene ancora copie aggiornate First-level cache Associata con l oggetto Session Second-level cache Associata con l oggetto SessionFactory 92

Hibernate: Strategie di caching Cache di primo livello: usata da Hibernate all interno dei confini di una singola transazione principalmente al fine di ridurre il numero di query SQL generate all interno di una transazione Ad es. se un oggetto è modificato diverse volte all interno della medesima transazione, Hibernate genera un unico statement SQL UPDATE alla fine della transazione, con tutte le modifiche Cache di secondo livello: mantiene dati al livello di Session Factory, utilizzabili da diverse transazioni (across transaction boundaries) Oggetti persistenti disponibili per l intera applicazione, non solo per l utente che sta eseguendo le query e per il SessionBean associato 93

Hibernate in azione Cinque ingredienti principali di una applicazione che fa uso di Hibernate per la gestione della persistenza: le classi di dominio realizzate in Java una base di dati (per noi realizzata in DB2) un file XML che definisce il mapping di ogni classe persistente uno o più file di configurazione di Hibernate le interfacce Hibernate per l'accesso alla base di dati: Session, Transaction e Query + package org.hibernate 94

Classi di dominio e DB Sappiamo già come realizzarli dalle slide precedenti Esempio: classe User e relativa tabella UTENTE : public class User { } private String nome; private String cognome; private String username; private String password; private String email; private Indirizzo indirizzo; public User(){} public User(String user){ username=user; } CREATE TABLE UTENTE( username VARCHAR(10) PRIMARY KEY, nome VARCHAR(15), cognome VARCHAR(15), cod_fis VARCHAR(16) UNIQUE, password VARCHAR(8), email VARCHAR(20), via VARCHAR(20), civico INT, cap VARCHAR(5), citta VARCHAR(15)); 95

File di mapping per le classi persistenti File XML che definisce come si mappano le proprietà delle classi Java persistenti sulle tabelle del DB Deve soddisfare la grammatica specificata all'interno di un apposito DTD chiamato hibernate-mapping-3.0.dtd N.B. Per verificare la correttezza sintattica del file XML, Hibernate cercherà il DTD all'interno del classpath e lo troverà nella libreria.jar di Hibernate (ammesso che il classpath la includa) qualora non dovesse trovare il DTD, Hibernate lo cercherà all'indirizzo specificato nella dichiarazione del DOCTYPE 96

File di mapping per le classi persistenti: Esempio File User.hbm.xml <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping> <class name="user" table="utente"> <id name="username" column="username"></id> <property name="nome" column= nome"></property> <property name="cognome" column= cognome"></property> <property name="email"></property> <property name="password"></property> </class> </hibernate-mapping> 97

File di mapping per le classi persistenti: Commenti L'elemento class dichiara il nome della classe persistente e la tabella a cui essa corrisponde dice a Hibernate come rendere persistente e caricare gli oggetti della classe User sfruttando la tabella UTENTE, ovvero ogni istanza è rappresentata da una tupla della tabella L'elemento id dichiara: il nome della proprietà della classe che gioca il ruolo di identificatore Importante: una classe persistente è sempre caratterizzata da una proprietà che ne identifica le istanze; una volta creato un oggetto della classe, tale proprietà non potrà essere modificata dalla applicazione il corrispondente metodo set può essere definito privato 98

File di mapping per le classi persistenti: Commenti il nome dell'attributo della tabella che identifica le tuple mappate su oggetti (primary key) L'elemento property dichiara il nome delle proprietà persistenti della classe e a quali attributi della tabella corrispondono; di default, nessuna proprietà è persistente Importante: come per la proprietà che identifica gli oggetti, il nome della proprietà indica ad Hibernate quali metodi set e get usare 99

File di configurazione per Hibernate Hibernate costituisce la parte dell'applicazione che gestisce la persistenza, ovvero che si connette al DB ha bisogno di avere le informazioni necessarie per effettuare la connessione, quali il DBMS, il driver JDBC, la base di dati, utente/password, etc. Un file XML fornisce tutte queste informazioni Tale file deve soddisfare la grammatica specificata nel DTD hibernate-configuration-3.0.dtd 100

File di configurazione per Hibernate: Esempio File hibernate.cfg.xml <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> <hibernate-configuration> <session-factory> <!-- Database connection settings --> <property name="hibernate.connection.driver_class"> com.ibm.db2.jcc.db2driver</property> <property name="hibernate.connection.url"> jdbc:db2://diva:deis.unibo.it:50000/tw_stud</property> <property name="connection.username">*****</property> <property name="connection.password">*****</property> 101

File di configurazione per Hibernate: Esempio <!-- SQL dialect --> <property name="dialect"> org.hibernate.dialect.db2dialect</property> <!-- JDBC connection pool (use C3P0) --> <property name="c3p0.min_size">5</property> <property name="c3p0.max_size">20</property> <property name="c3p0.timeout">300</property> <property name="c3p0.max_statement">50</property> <!-- Show and print nice SQL on stdout --> <property name="show_sql">true</property> <property name="format_sql">true</property> <!-- List of XML mapping files --> <mapping resource="user.hbm.xml" /> </session-factory> </hibernate-configuration> 102

File di configurazione per Hibernate: Commenti L'elemento session-factory definisce le impostazioni per l'accesso a un particolare DB Le proprietà il cui nome hanno la forma (hibernate).connection.* contengono le informazioni necessarie per impostare la connessione JDBC La proprietà dialect specifica la variante di SQL che deve generare Hibernate 103

File di configurazione per Hibernate: Commenti Le proprieta c3p0.* indicano le impostazioni necessarie a configurare il software c3p0 per il pooling di connessioni min size: numero minimo di connessioni che devono essere pronte in ogni momento max size: numero massimo di connessioni aperte gestite dal pool timeout: tempo al termine del quale una connessione aperta non più usata viene rimossa max statements: numero di prepared statements che sono mantenuti in cache Infine mapping include l elenco dei file di mapping XML 104

Le interfacce Hibernate Tre sono le interfacce principali per l'accesso al DB, tutte appartenenti al package org.hibernate Session: ogni istanza rappresenta una sessione di comunicazione tra applicazione e base di dati comprende i metodi per salvare/caricare oggetti nella/dalla base di dati Transaction: ogni istanza rappresenta una transazione maggiore disaccoppiamento dell'applicazione: non è necessario usare l'api JDBC per impostare una transazione 105

Le interfacce Hibernate Gioca il ruolo di gestore di transazioni in un sistema che accede a più DB all'interno di una unica unità di lavoro di sistema Query: interfaccia che permette di creare ed eseguire query sia nel linguaggio di query di Hibernate (HQL) che in SQL che usino al loro interno delle variabili (:nomevaraibile) 106

Interfacce Hibernate: Esempio d'uso File Bid.java package bid; import java.util.*; import org.hibernate.*; import persistence.hibernateutil; public class Bid { public static void main(string[] args) { //First unit of work Session session = HibernateUtil.getSessionFactory().openSession(); Transaction tx = session.begintransaction(); User user = new User("pippo"); String userid = (String) session.save(user); tx.commit(); session.close(); 107

Interfacce Hibernate: Esempio d'uso //Second unit of work session = HibernateUtil.getSessionFactory().openSession(); tx = session.begintransaction(); user = (User) session.get(user.class,userid); user.setnome("filippo"); tx.commit(); session.close(); //Third unit of work session = HibernateUtil.getSessionFactory().openSession(); tx = session.begintransaction() List users = session.createsqlquery("select * from UTENTE order by username").addentity(user.class).list(); System.out.println(users.size()+" user(s) found: "); for (Iterator iter= users.iterator(); iter.hasnext(); ) { User userid = (User) iter.next(); System.out.println (userid.getnome()); } tx.commit(); session.close(); HibernateUtil.shutdown(); //Shutting down the application } } 108

Interfacce Hibernate: Commenti L'utilizzo della interfaccia Transaction imposta l'autocommit a false necessità di chiamare il metodo commit Tutti i comandi SQL sono generati a runtime La prima unità di lavoro, quando eseguita, corrisponde ad effettuare sul DB un comando SQL simile a: insert into UTENTE (USERNAME,NOME,COGNOME, COD_FIS,PASSWORD,EMAIL,VIA,CIVICO,CAP,CITTA) values ( pippo, null, null, null, null, null, null, null, null, null); 109

Interfacce Hibernate: Commenti La seconda unità di lavoro mostra l'abilita di: caricare un oggetto dalla base di dati, a partire dalla classe di cui è istanza e dal suo identificatore il metodo get(class,serializable) restituisce una istanza della classe persistente data in input caratterizzata dall'identificatore in input, e null se la suddetta istanza non esiste effettuare un dirty checking automatico: senza che sia richiesto esplicitamente di fare l'update dell'istanza, Hibernate si accorge delle modiche apportate sulla proprietà nome ed aggiorna automaticamente la base di dati 110

Interfacce Hibernate: Commenti La terza unita di lavoro mostra come è possibile incapsulare una query di accesso al DB e ricavare dai risultati oggetti del dominio questo tipo di accesso deve essere limitato a quei casi in cui è necessario effettuare una ricerca sul DB non di tipo diretto, ad esempio, FindByCriteria 111

Inizializzazione di Hibernate: SessionFactory Per inizializzare Hibernate, si costruisce un oggetto SessionFactory a partire da un oggetto Configuration Un oggetto Configuration, sostanzialmente, rappresenta il file di configurazione di Hibernate SessionFactory sessionfactory = new Configuration().configure().buildSessionFactory(); quando new Configuration()è invocato, Hibernate cerca un file chiamato hibernate.properties e tutte le impostazioni definite sono associate all'oggetto di Configuration quando configure()è invocato, Hibernate cerca il file hibernate.cfg.xml 112

Inizializzazione di Hibernate: SessionFactory Nella maggior parte delle applicazioni, SessionFactory deve essere istanziato una sola volta durante la fase di inizializzazione di Hibernate, e gioca il ruolo di gestore delle sessioni, nel senso che ogni istanza di Session deve essere creata a partire da lui è buona prassi realizzare una classe HibernateUtil per l'inizializzazione di Hibernate e la gestione della singola istanza di SessionFactory 113

Gestore delle sessioni: HibernateUtil File HibernateUtil.java package persistence; import org.hibernate.*; import org.hibernate.cfg.*; public class HibernateUtil { private static SessionFactory sessionfactory = inithibernateutil(); private static SessionFactory inithibernateutil(){ try { return new Configuration().configure().buildSessionFactory(); } catch (HibernateException ex) { throw new ExceptionInInitializerError(ex); } } public static SessionFactory getsessionfactory() { return sessionfactory; } public static void shutdown() { getsessionfactory().close(); //Close caches and connection pools } } 114

Mappare una classe Java significa... Stabilire una corrispondenza tra le sue istanze e le tuple della tabella corrispondente Mappare il suo identificatore Mappare le sue proprietà persistenti proprietà che sono valori proprietà che sono istanze di una altra classe di dominio Java 115

Mappare gli identificatori delle classi di dominio Dal punto di vista sintattico, una proprietà che identifica una classe deve essere mappata attraverso l'elemento XML <id> (che deve essere definito) <id> può avere un elemento figlio <generator> che deve avere un attributo class che specifica una classe Java che implementa l'interfaccia org.hibernate.id.identifiergenerator e che viene usata per generare identificatori unici ; Hibernate viene fornito con delle classi built-in per generare identificatori, tra le altre: assigned: significa che l'applicazione assegna l'identificatore all'istanza prima che sia chiamato il metodo save - questo è il comportamento di default se generator non compare native: usa i generatori di identificatori forniti dal DBMS sottostante; mantiene il mapping portabile 116

Mappare proprietà delle classi di dominio Abbiamo già visto come mappare una proprietà persistente di una classe quando la stessa corrisponde a un valore con molteplicità massima pari a uno mediante l uso dell'elemento XML property Quando invece una proprietà è una collezione omogenea di valori gestiti da una altra tabella, allora nel file di mapping si definisce un elemento apposito, quale Set, List, ecc. Si rimanda alla documentazione e al materiale dell esercitazione guidata in laboratorio per dettagli Diciamo qualcosa in più sul sistema di tipi di Hibernate 117

Il sistema di tipi di Hibernate I tipi Hibernate sono di fatto dei convertitori che traducono da tipi Java a tipi SQL e viceversa La maggior parte dei tipi built-in di Hibernate hanno lo stesso nome del tipo Java che mappano Possono però esserci più tipi Hibernate per uno stesso tipo Java bisogna allora indicare nel file di mapping il tipo di mapping che Hibernate deve usare 118

Tipi primitivi di Hibernate: Corrispondenze SQL-Java 119

Tipi di dati Hibernate sulle date e il tempo 120

Come usare i tipi di Hibernate nei mapping: Esempio <class name="item" table="item"> (...) <property name="giornoinizio" type="time" column="inizio"/> </class> N.B. Se non specifichiamo il tipo di Hibernate, allora Hibernate usa la reflection, ovvero risale al tipo Java della proprietà giornoinizio della classe Item e assume un comportamento di default se abbiamo definito la proprietà giornoinizio di tipo java.util.date, Hibernate cerca di convertirla nel tipo TIMESTAMP (diverso da TIME) 121