UNIVERSITA DI FIRENZE Facoltà di Ingegneria. Persistenza Applicazioni Enterprise Uso dei modelli

Transcript

1 UNIVERSITA DI FIRENZE Facoltà di Ingegneria Persistenza Applicazioni Enterprise Uso dei modelli 1

2 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

3 Problemi 3

4 Struttura a livelli A cosa ci vogliamo portare per il Dominio Logica applicativa 4

5 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

6 Un modo elementare I dati (Data Objects) sono salvati/recuperati 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 vera soluzione 6

7 .Un modo elementare Se ci basta un file system (non una vera base dati) Salvare/caricare i dati (data objects) su/da un file system: Serializzazione (Java) Salva l intero grafo degli oggetti (con tutti i loro attributi ecc.) Uso di librerie, p.e. XStream Genera file XML contenenti il grafo degli oggetti Costruisce un grafo di oggetti a partire dal file XML (conforme) Vediamolo! 7

8 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> 8

9 Siamo seri! Usare una base di dati (relazionale) Tenere in memoria solo i data objects che in quel momento servono (oggetti transienti) Ragionare per Transazioni Richiede l adattamento dei due mondi Oggetti Tabelle 9

10 Mismatch 10

11 Come si risolve? 11

12 Modo tradizionale: Procedure Come di utente si che risolve? operano sui dati letti/scritti da/su la Base di dati ODBC (Open Data Base Connectivity) JDBC (Java Data Base Connectivity) Logica di dominio attraverso le entità che lo compongono. Richiede la trasformazione di oggetti in tabelle e viceversa 12

13 Come si risolve? Se l applicazione è complessa la strada è per forza questa: costi di sviluppo (progrmz, testing..) manutenzione ecc 13

14 Soluzione 14

15 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 15

16 Mappatura (impedance mismatch) Mondo OO Mondo RDB Mappatura Negli oggetti e nelle tabelle Solo negli oggetti 16

17 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) 17

18 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 18

19 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"); 19

20 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 20

21 Esempio Con riferimento ad 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; } 21

22 .Esempio Nell applicazione: Partecipante p = agenzia.getpartecipante( BCC... ) Sono state inserite linee di codice per la gestione della persistenza entro 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 Evitare!.ma Come? 22

23 ..Come? Non ci sarebbe niente di strano se anche i ServiceObjects avessero accesso a JDBC (p.e. per istanziare i DataObjects) Ma in tal caso la conoscenza della struttura della base di dati verrebbe portata anche nei service objects!!! Ci vuole una soluzione meno invasiva 23

24 ..Come? Ricorrendo 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 gli stessi. Si introducono i 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) 24

25 Mappatura manuale e trasparente (con JDBC) Come si trasforma 25

26 Effetto del DAO Trasparente: I Data Object possono essere codificati come normali classi transienti Cliente non ha richiesto nessuna modifica relativa alla persistenza 26

27 Effetto del DAO Ovviamente questi metodi devono avere parametri appropriati 27

28 DAO in azione 28

29 Valutazione DAO + E trasparente (l unica minima variazione è nell istanziare e usare i DAO) 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 Difficoltà nel testing (del codice SQL) Per semplificare lo sviluppo sono stati resi disponibili i cosiddetti i framework di persistenza (o più semplicemente ORM) 29

30 Persistence framework Un framework di persistenza gestisce la mappatura tra oggetti e base dati in modo automatico e trasparent Open source: Hibernate, OJB (Apache ObJectRelationalBridge), CAYENNE (Apache), JULP (Java Ultra-Lite Persistence), TJDO,... Commerciali: TopLink (Oracle), JDO Genie, JDO Toolkit, 30

31 Persistence Framework (Hibernate) Fa (quasi) tutto lui 31

32 Persistence framework I Data Object sono normali oggetti (transienti) 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. 32

33 Hibernate in azione Sono spariti i metodi save(), load().. 33

34 Lavora con i Metadati di Mapping 34

35 Hibernate 35

36 Architettura con Hibernate Di norma XML 36

37 E bene mantenere i DAO Conviene sempre 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. 37

38 Hibernate e DAO 38

39 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 39

40 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); 40

41 E ancora migliorabile I Service Object implementano la logica di business Ma devono tenere anche conto di aspetti trasversali, legati alla logica di sistema (logging, transaction management, ecc.) Finisce che i Service Object vengono sporcati con aspetti estranei alla logica di business Ci sono dei framework che liberano i Service Object degli aspetti di sistema e permettono di definire Service Object in cui si tiene conto della sola logica di business. Uno di questi è Spring (Apache) 41

42 Meglio ancora JPA JPA (Java Persistence API) Semplifica di molto il trattamento della persistenza Si tratta di aggiungere poche righe al codice Java (POJO) public class private Integer employeeid; } Si può anche fare a meno dei DAO 42

43 Meglio ancora JPA EJBv3.0 JPA (Java Persistence API) Semplifica di molto il trattamento della persistenza Si tratta di aggiungere poche righe al codice Java (POJO) public class private Integer employeeid; } Si può anche fare a meno dei DAO 43

44 Meglio ancora JPA EJBv3.0 JPA (Java Persistence API) Semplifica di molto il trattamento della persistenza Si tratta di aggiungere poche righe al codice Java (POJO) public class private Integer employeeid; } Si può anche fare a meno dei DAO 44