UNIVERSITA DI FIRENZE Facoltà di Ingegneria Persistenza Applicazioni Enterprise Uso dei modelli 1
IL problema della persistenza APPLICAZIONE (programmi) (oggetti) DATI PERSISTENTI (file, record) (basi di dati) I programmi trattano oggetti (Stato, comportamento, associazioni) La base di dati è fatta di tabelle (valori, relazioni ) 2
Schema AE 3
Struttura a livelli A cosa ci vogliamo portare nel Dominio Logica applicativa 4
Terminologia Data Object Sono le entità proprie del dominio applicativo ESEMPI: Fattura, Ordine, Cliente, Impiegato, Prestito, Escursione, Documento, Prenotazione, Pagamento, ecc. Spesso vengono anche indicati come Value Object (o Business object) Service Object Sono gli oggetti che implementano la logica applicativa ESEMPI: Gestore degli ordini, Controllo Pagamenti, Assegnazione lavoro, Registrazione prenotazione, ecc. Indicati anche come Applicative Object, Managers, Control Objects (?), ecc. 5
Un modo elementare (prima di passare a un DB) I dati (Data Objects) possono essere salvati/recuperati su/da un file All avvio del programma viene caricato il file con i dati (tutto il grafo del modello di dominio) Tutti gli oggetti sono quindi in memoria La logica applicativo opera sugli oggetti in memoria Al termine il grafo degli oggetti del modello di dominio viene di nuovo salvato (come con Word, Excel, StarUML, ) Non è una soluzione accettabile per applicazioni enterprise 6
.Un modo elementare Se ci basta un file system (non una vera base dati) Serializzazione (Java) Salva/recupera l intero grafo degli oggetti (con tutti i loro attributi ecc.) Un po ostica da manegiare Uso di librerie, p.e. XStream Si appoggia sulla serializzazione di Java Genera file XML contenenti il grafo degli oggetti Costruisce un grafo di oggetti a partire dal file XML (conforme) 7
XML (Extended markup Language) Esempio (da wikipedia) <?xml version="1.0" encoding="utf-8"?> <utenti> <utente> <nome>luca</nome> <cognome>ruggero</cognome> <indirizzo>milano</indirizzo> </utente> <utente> <nome>max</nome> <cognome>rossi</cognome> <indirizzo>roma</indirizzo> </utente> </utenti> Vediamolo! 8
Siamo seri! Usare una base di dati (relazionale) Tenere in memoria solo i data objects che in quel momento servono Ragionare per Transazioni Richiede l adattamento dei due mondi Oggetti Tabelle 9
Mismatch 10
Mappatura (impedance mismatch) Mondo OO Mondo RDB Mappatura Va bene per relazioni 1:1 e 1:N Nel caso di relazione N:N ci vuole una tabella di incrocio 11
Mappatura (impedance mismatch) Mondo OO Mondo RDB Mappatura Negli oggetti e nelle tabelle Solo negli oggetti 12
Soluzione (obiettivo) 13
Mappatura Manuale: Il codice SQL per l accesso ai dati viene prodotto manualmente dal programmatore e integrato nell applicazione Automatica: Attraverso i metadati di mappatura il livello di persistenza provvede ad accedere direttamente ai dati (genera automaticamente il codice SQL necessario) 14
Mappatura Trasparente: Il modello di dominio non è sottoposto ad alcun vincolo dovuto allo strato di persistenza; le entità (oggetti corrispondenti ai dati) sono transienti e non sanno di essere persistenti. Invasiva: Il modello di dominio deve implementare e/o estendere classi e interfacce per implementare la mappatura. Le entità persistenti vengono codificate in modo diverso dalle entità transienti (p.e., hanno i metodi per salvarsi, aggiornarsi, ecc.) T I M A 15
ODBC/JDBC ODBC (Open Data Base Connectivity): API standard di connessione ai DBMS (linguaggio C) JDBC: versione di ODBC per programmi in Java Richiedono un driver specifico per ogni distinto DBMS (Oracle, MySQL, ) 16
Mappatura manuale con JDBC JDBC: API standard di JAVA verso il DBMS relazionale (uso di SQL) Accesso alla base dati: Apertura di una connessione verso la base di dati (istanziazione dell'oggetto con ) Preparazione di uno statement SQL (istanziazione dell'oggetto stmt) Esecuzione della query (tramite il metodo executequery() di stmt ) ottenendo un result set. Statement stmt = con.createstatement(); resultset rs = stmt.executequery("select * from PARTECIPANTE"); 17
Mappatura manuale con JDBC Come fare: Lasciare i Service Objects invariati Mettere nei Data Object le funzionalità che servono a: Cercare nella base dati Istanziare gli oggetti e assegnare agli attributi i valori letti da DB Salvare gli oggetti (aggiornare la base di dati) copiare i valori degli attributi nei campi delle righe corrispondente 18
Esempio (rif. Agenzia) Nell applicazione: Partecipante p = agenzia.getpartecipante( BCC... ) Bisogna inserire linee di codice entro Agenzia per recuperare gli oggetti dal DB (persistenza attraverso i Data Objects (Agenzia) E una soluzione invasiva : le entità di dominio vengono sporcate dal codice di persistenza, violando la separazione tra il livello di dominio e quello di persistenza 19
Esempio Cosa serve in Agenzia public Partecipante getpartecipante(string cf){ Statement stmt = con.createstatement(); ResultSet rs = stmt.executequery("select * from PARTECIPANTE"); while (rs.next()){ String cfx = rs.getstring("cf"); if (cfx == cf) { Partecipante p = new Partecipante(cF); p.setname(rs.getstring("name")); return p; } } return null; } L oggetto di dominio è stato stravolto Meglio evitare! Ma come? 20
Per inciso M. Fowler, Patterns of Enterprise Application Architecture Addison Wensley Descrive un ottantina di pattern Una parte consistente è relativa al problema della persistenza (mapping, caricamento, ecc) 21
..Come? Non ci sarebbe niente di strano se anche i ServiceObjects avessero accesso a JDBC (p.e. per istanziare i DataObjects) E anche peggio: la conoscenza della struttura della base di dati verrebbe portata anche nei service objects!!! Ci vuole una soluzione meno invasiva 22
..Come? Ricorrere al criterio classico dell ingegneria del software: Nascondere, incapsulare a parte i dettagli relativi alla mappatura in modo che i Data Object e i Service Object restino il più possibile gli stessi (qualcosa andrà comunque modificata) SOLUZIONE: DAO (Data Access Object), oggetti che hanno la responsabilità della mappatura Usati dai Service Object per ottenere i Data Object Un DAO per ogni classe di oggetti Rendono inutile il Contenitore (nel nostro caso Agenzia) 23
Evitare 24
Effetto del DAO Trasparente: I Data Object possono essere codificati come normali classi POJO Il Data Object Cliente non ha richiesto nessuna modifica relativa alla persistenza 25
Effetto del DAO Ovviamente questi metodi devono avere parametri appropriati 26
Mappatura manuale e trasparente (con JDBC e DAO) Come si trasforma 27
Mappatura manuale e trasparente (con JDBC e DAO) Come si trasforma Invariati 28
Mappatura manuale e trasparente (con JDBC e DAO) Come si trasforma Alcune variazioni Invariati 29
Mappatura manuale e trasparente (con JDBC e DAO) Come si trasforma Alcune variazioni Invariati Nuovi 30
DAO in azione 31
E questo? Attenzione!!! Vediamolo! 32
E questo? Attenzione!!! Presuppone che la creazione dell oggetto Client abbia anche creato gli oggetti ad esso collegati (il CC) Di norma non sarà così Vediamo i DAO 33
Valutazione DAO + E (quasi) trasparente Istanziare i DAO Chiedere ai DAO il Load/Store di oggetti Richiede la scrittura manuale dei DAO (codice SQL), per la gestione della persistenza Quando il dominio è complesso la produzione del codice SQL diventa molto costosa (tirare dentro tutto il grafo o solo una parte?) Difficoltà nel testing (del codice SQL) Per semplificare lo sviluppo sono stati resi disponibili i cosiddetti i framework di persistenza (o più semplicemente ORM) 34
Persistence framework Un framework di persistenza gestisce la mappatura tra oggetti e base dati in modo automatico e trasparente Open source: Hibernate, OJB (Apache ObJectRelationalBridge), CAYENNE (Apache), JULP (Java Ultra-Lite Persistence), TJDO,... Commerciali: TopLink (Oracle), JDO Genie, JDO Toolkit, 35
Persistence Framework (Hibernate) Fa (quasi) tutto lui 36
Persistence framework I Data Object sono normali oggetti (POJO) nel dominio I metadati specificano quali sono gli oggetti da considerare persistenti C è un Persistence Manager: fintantoché un oggetto nel dominio è agganciato al persistence manager, il framework rileva i suoi cambiamenti di stato e lo sincronizza con il data base SQL generation Commit and rollbacks Caching Prefetching Ecc. 37
Hibernate in azione Sono spariti i metodi save(), load().. Ma si usano i metodi di Session 38
Lavora con i Metadati di Mapping 39
Hibernate 40
Architettura con Hibernate Di norma XML 41
E bene mantenere i DAO Conviene comunque avere i DAO tra il livello di persistenza e il livello dei service objects Hibernate semplifica l accesso ma ha pur sempre degli aspetti che sanno di base di dati (aprire/chiudere le sessioni, aprire/chiudere le transazioni, riconoscere le eccezioni che genera,..) Meglio nascondere questi aspetti entro i DAO, in modo che la logica applicativa veda un interfaccia pulita. 42
Hibernate e DAO 43
In pratica Interfaccia del DAO delle Escursioni public interface EscursioneDAO extends GenericDAO<Escursione> { public List<Escursione> getbypartecipante(partecipante p); public List<Escursione> findbydate(data d) ; } GenericDAO è un interfaccia ancora più astratta che definisce operazioni CRUD da prevedere per qualunque tipo di DAO [save(), delete(), ] Sono oggetti 44
In pratica public class EscursioneDAOImpl extends GenericAbstractHibernateDAO<Escursione> implements EscursioneDAO { public List<Escursione> getbypartecipante( Partecipante p) { return find("from Escursione e where :partecipante in elements(e.iscrittilista)", "partecipante",p); } public List<Escursione> findbydate(data d) { return find("from Escursione where data = :data", "data", d); 45
Meglio ancora JPA JPA (Java Persistence API) Semplifica di molto il trattamento della persistenza Si tratta di aggiungere poche righe al codice Java (POJO) Esempio @Entity public class Partecipante{ @Id private Integer employeeid; ::::::: } Si può anche fare a meno dei DAO 46
Modo tradizionale: Sintesi: Procedure di utente cosa che operano conviene? sui dati letti/scritti da/su la Base di dati Logica di dominio attraverso le entità che lo compongono. 47
Sintesi: cosa conviene? Se l applicazione è complessa la strada è per forza questa: costi di sviluppo (progrmz, testing..) manutenzione ecc 48
Sintesi: cosa conviene? 49