Design Patterns - Enterprise Patterns (part 2)
•
3 j'aime•1,784 vues
Design Patterns - Enterprise Patterns (part 2) - - - Enterprise Patterns ( Patterns of Enterprise Application Architecture Core J2EE Patterns Integration Patterns) Business Tier Data Transfer Object (DTO) Business Object (BO) Service Locator Application Service Integration Tier Data Access Object (DAO) Domain Store Web Service Broker Other Patterns: Analysis patterns Architectural patterns Design patterns Enterprise patterns GRASP patterns Implementation patterns J2EE Core patterns SCM patterns
Recommandé
Contenu connexe
En vedette
En vedette (20)
Similaire à Design Patterns - Enterprise Patterns (part 2)
Similaire à Design Patterns - Enterprise Patterns (part 2) (20)
Plus de Fabio Armani
Plus de Fabio Armani (17)
Design Patterns - Enterprise Patterns (part 2)
- 2. fabio.armani
- 3. Overview • Analysis pa4erns • Architectural pa4erns • Design pa4erns • Enterprise pa4erns • GRASP pa4erns • ImplementaAon pa4erns • J2EE Core pa4erns • SCM pa4erns
- 5. Enterprise Pa4erns • Pa4erns of Enterprise ApplicaAon Architecture • Core J2EE Pa4erns • IntegraAon Pa4erns
- 6. Enterprise Pa4erns > books
- 8. Core J2EE Pa4erns • PresentaAon Tier • Business Tier • IntegraAon Tier
- 9. Core J2EE Pa4erns • PresentaAon Tier – ApplicaAon Controller – Composite View – Context Object – Dispatcher View – Front Controller – IntercepAng Filter – Service To Worker – View Helper
- 10. Core J2EE Pa4erns • Business Tier – Data Transfer Object (DTO) – Business Object (BO) – Service Locator – ApplicaAon Service • IntegraAon Tier – Data Access Object (DAO) – Domain Store – Web Service Broker
- 11. Core J2EE Pa4erns • Business Tier – Data Transfer Object (DTO) – Business Object (BO) – Service Locator – ApplicaAon Service • IntegraAon Tier – Data Access Object (DAO) – Domain Store – Web Service Broker
- 12. PresentaAon Tier Pa4ern • Front Controller • View Helper • Composite View • Dispatcher View
- 13. Business Tier Pa4ern • Data Transfer Object • Business Object • Service Locator • ApplicaAon Service • Business Delegate • Value List Handler • Session Facade • Composite EnAty • Transfer Object • Transfer Object Assembler
- 14. Business Tier Pa4ern • Data Transfer Object • Business Object • Service Locator • ApplicaAon Service • Business Delegate • Value List Handler • Session Facade • Composite En7ty • Transfer Object • Transfer Object Assembler Ejb Pattern
- 15. DATA TRANSFER OBJECT PoEAA -‐ pag. 117
- 16. DATA TRANSFER
- 17. Data Transfer Object (DTO) Descrizione • Il DTO (Data Transfer Object ) è un pa4ern che risulta essere molto uAle lavorando in applicazioni Apicamente distribuite, in cui la maggior parte delle chiamate e delle invocazioni è fa4a in maniera remota (macchine diverse).
- 18. Data Transfer Object (DTO) Descrizione • L' Ogge4o di Trasferimento DaA o Data Transfer Object (in sigla DTO) è un design pa4ern usato per trasferire daA tra so4osistemi di un'applicazione soware. • I DTO sono spesso usaA in congiunzione con gli ogge] accesso daA per recuperare i sudde] da una base di daA. • La differenza tra gli ogge] di trasferimento daA e gli ogge] business o gli ogge] d'accesso daA è che un DTO non ha alcun comportamento se non di archiviare e recuperare i suoi daA.
- 19. Data Transfer Object (DTO) Presenta<on Business Data Access
- 20. Data Transfer Object (DTO) Scopo • Una buona organizzazione di una archite4ura enterprise è cosAtuita normalmente di un straAficazione basata almeno sui seguenA livelli: – strato client applicaAvo (esempio le ac7ons di una applicazione Struts), – strato client di comunicazione con il server (BD), – strato server di session façade, – uno o più straA applicaAvi di sessione, strato data model (en7ty beans).
- 21. Data Transfer Object (DTO) Scopo
- 22. Data Transfer Object (DTO) Soluzione
- 23. Data Transfer Object (DTO) Scopo • In una tradizionale archite4ura EJB, un DTO ha un duplice scopo: – porre riparo al problema derivante dal fa4o che gli en7ty beans pre-‐ ejb 3.0 (in J2EE) non sono serializzabili; – definire implicitamente una fase di assemblaggio dove tu] i daA che devono essere usaA da una view sono prelevaA e marshallizza7 nei DTO prima di resAtuire il controllo al presenta7on layer.
- 24. Data Transfer Object (DTO) Problema • Si vogliono trasferire molA daA lungo più layers di un’applicazione. In parAcolare, si vuole che il client possa accedere ai componenA di diversi layer per recuperare o aggiornare daA. • Inoltre, in uno scenario di invocazione remota, sorge il problema del network overhead a causa delle numerose chiamate al server, sia per il recupero dei daA sia per il salvataggio degli stessi.
- 25. Data Transfer Object (DTO) Soluzione • UAlizzare un Data Transfer Object per incapsulare i daA di business. Una singola chiamata a un metodo è usata per inviare e recuperare il Transfer Object. • Quando il cliente richiede dei daA di business, il DTO viene istanziato e popolato con i rispe]vi valori e poi passato al client. • Esso viaggia lungo tu] gli straA dell’applicazione.
- 26. Data Transfer Object (DTO) Presenta<on Business Data Access DTO DTO
- 27. Data Transfer Object (DTO) Soluzione
- 28. Data Transfer Object (DTO) CaraAeris<che • Il DTO è un ogge4o dotato di cara4erisAche parAcolari: – è serializzabile, – conAene solo proprietà e – non ha all’interno alcuna logica di business. • Come dice lo stesso nome del pa4ern è quindi un oggeHo che serve per trasferire dei da7. • In uno scenario di invocazione remota, fare numerose chiamate al server per o4enere dei daA causa un network overhead non indifferente; per questo moAvo bisogna cercare di minimizzare queste chiamate al server e il DTO ci aiuta.
- 29. Data Transfer Object (DTO) StruAura
- 30. Data Transfer Object (DTO) Esempio: interazione senza uAlizzo DTO
- 31. Data Transfer Object (DTO) Esempio: interazione con server mediante DTO
- 32. Data Transfer Object (DTO) Esempio • Possiamo infa] inserire nel DTO tu4e le informazioni che vogliamo farci resAtuire dal server in modo tale da fare una sola chiamata. • Stesso ragionamento se vogliamo salvare delle informazioni, infa] fare più chiamate per il salvataggio è oneroso, invece farne una sola passando i daA da salvare nel DTO è più efficiente.
- 33. Data Transfer Object (DTO) Implementazione • Vi sono due approcci base per la costruzione del DTO: – Creare un DTO per ogni enAtà nel modello dei daA. Questo approccio consente una completa trasposizione del modello e quindi una completa interazione con le enAtà in o]ca di recupero informazioni o salvataggio. – Creare un DTO thin, inserendo solo le informazioni di cui abbiamo bisogno. Questo ha pro e contro, infa] un vantaggio è sicuramente l’aumento delle prestazioni visto che i daA da serializzare e deserializzare saranno di meno, tu4avia lo svantaggio è che nel momento in cui vogliamo un campo in più dovremmo modificare lato codice il DTO con tu4e le conseguenze che ne derivano.
- 34. Data Transfer Object (DTO) Implementazione • Considerando che un proge4o è sogge4o a conAnui cambiamenA nei requisiA, probabilmente se non ci sono problemi di prestazioni, la prima scelta è quella più opportuna. • Ecco un esempio, in Java, di un DTO.
- 35. Data Transfer Object (DTO) Implementazione • Considerando che un proge4o è sogge4o a conAnui cambiamenA nei requisiA, probabilmente se non ci sono problemi di prestazioni, la prima scelta è quella più opportuna. • Ecco un esempio, in Java, di un DTO.
- 36. Data Transfer Object (DTO) public class StudenteDTO implements Serializable { private int age; private String nome; private String cognome; public int getAge() { return age; } public void setAge(int age) { this.age = age; } public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getCognome() { return cognome; } public void setCognome(String cognome) { this.cognome = cognome; } }
- 37. Data Transfer Object (DTO) Implementazione • Come potete notare, dal punto di vista pre4amente di codice Java, un DTO è un POJO che implementa l’interfaccia Serializable.
- 39. Data Transfer Object (DTO) // esegue una operazione di ricerca per chiave primaria sulla entità articolo // e ricava la interfaccia locale dell'entity bean public ArticleDTO articleFindByPrimaryKey(String id) throws EJBException { try { ArticleLocal articleLocal = articleLocalHome.findByPrimaryKey(id)); Hashtable articleDTO = new hashtable(); articleDTO.put("articleName", articleLocal.getName()); articleDTO.put("abstractText", articleLocal.getAbstractText()); articleDTO.put("notes", articleLocal.getNotes()); articleDTO.put("title", articleLocal.getTitle()); articleDTO.put("subTitle", articleLocal.getSubTitle()); articleDTO.put("introduction", articleLocal.getIntroducion()); articleDTO.put("body", articleLocal.getBody()); articleDTO.put("id", articleLocal.getId()); articleDTO.put("status", articleLocal.getStatus()); return articleDTO; } catch (ObjectNotFoundException onfe) { logger.debug("nessun articolo trovato con Id=" + id); return null; } catch (Exception e) { throw new EJBException(e.getMessage()); } }
- 40. Data Transfer Object (DTO) Sequence diagram
- 41. Data Transfer Object (DTO)
- 42. Data Transfer Object (DTO) Conseguenze • Le conseguenze che derivano dall’uAlizzo dei Data Transfer Objects sono: – riduzione del traffico di rete – semplificazione delle interfacce remote – riduzione del codice duplicato – trasferimento di una maggior quanAtà di daA in meno chiamate remote
- 43. BUSINESS OBJECT PoEAA -‐ pag. 117
- 44. BUSINESS OBJECT
- 45. Business Object Problema • Si ha un’applicazione con un modello conce4uale complesso, dotato di una logica di business sofisAcata, con regole di validazione complesse e ogge] complessi correlaA. • Si vuole separare lo stato di business e il relaAvo comportamento dal resto dell’applicazione, incrementandone così coesione e riusabilità. • Inoltre, si vuole evitare la duplicazione del codice.
- 46. Business Object Data Access Object Data Access Object Service Service Service Business Tier Integration Tier I servizi del business tier accedono direttamente ai sistemi legacy, o attraverso dei data access object DBMS
- 47. Business Object Data Access Object Data Access Object Service Service Service Business Tier Integration Tier DBMS Utilizzare Business Object che incapsulano dati e logica e che delegano ad altri componenti la loro persistenza
- 48. Business Object Data Access Object Data Access Object Service Service Service Business Tier Integration Tier BO BO Utilizzare Business Object che incapsulano dati e logica e che delegano ad altri componenti la loro persistenza DBMS
- 49. Business Object Soluzione • Si uAlizza un insieme di Business Objects per separare i daA di business dalla logica di business usando un object model. • Si implementano un insieme di classi che rappresentano un ulteriore strato all’interno dell’applicazione che incapsulino i daA di business, così da separare la logica di business dai daA di business.
- 50. Business Object Soluzione • Viene creato un layer di Business Object che rappresentano il domain model • Perme4e di separare il modello di daA dalla sua persistenza • Aumenta la riusabilità del codice
- 51. Business Object: strategie Implementazioni Apiche: • BO come POJO, con un meccanismo di persistenza Apo: • Data Access Object à Integra7on Tier PaHern • JDO • Tool di persistenza -‐ ORM (Hibernate, ...) • BO come Enterprise Java Bean (EJB) • CMP • BMP
- 52. Business Object Conseguenze • Tra le conseguenze che derivano dall’uAlizzo di tale pa4ern abbiamo: – evita la duplicazione del codice e favorisce la manutenibilità dello stesso – separa la logica di persistenza dalla logica di business – promuove un’archite4ura di Apo service-‐oriented – aggiunge un ulteriore strato di indirezione
- 53. APPLICATION SERVICE PoEAA -‐ pag. 117
- 54. ApplicaAon Service Spesso è difficile esprimere tu4a la logica applicaAva in termini di business object • use-‐case complessi e/o arAcolaA • aumenta l’accoppiamento degli ogge] del domain model • difficile ed improprio gesAre nei BO problemaAche di transazionalità o sicurezza
- 55. ApplicaAon Service Client ApplicationService - accedes BusinessObject DataAccessObject Service - uses 0..* - uses 0..* - uses 0..*ServiceFacade «Pojo» Helper Centralizza l’invocazione della logica di business in uno strato di servizi
- 56. ApplicaAon Service • Centralizza la logica riusabile, evitando duplicazioni di codice • Può gesAre problemaAche di transazionalità e sicurezza • Introduce un nuovo livello (Service Layer) all’interno del Business Tier
- 57. ApplicaAon Service E’ la base per la creazione di un Service Layer Integration Layer Domain Model (in Business Layer) Bo Bo Service Layer (in Business Layer) Service Service PresentaAon Batch
- 58. ApplicaAon Service Command Strategy Client ApplicationService ServiceFacade «Pojo» Helper ApplicationController - invokes CommandFactory Command + execute ( ) - uses - invokes - creates - invokes
- 59. SERVICE LOCATOR PoEAA -‐ pag. 117
- 60. Service Locator L’accesso ai componenA di business può essere complesso Client Ejb Anche utilizzando JNDI il codice necessario ad effettuare queste operazioni è poco leggibile e duplicato POJO Jms Service
- 61. Service Locator Client Ejb Db ServiceLocator Nasconde la complessità di lookup e creazione Fornisce una modalità di accesso uniforme Memorizza in cache i dati Service
- 62. Service Locator Client «Singleton» ServiceLocator- uses 1 1..* TargetService - _looksup - accesses Cache - mantains - caches InitialContext- creates/uses RegistryService - refers - resolves Una implementazione tipica
- 63. BUSINESS DELEGATE PoEAA -‐ pag. 117
- 64. Business Delegate Quando accedo ad un client ad un servizio remoto (Ejb, Jms) il codice di connessione ed invocazione è complesso e mescolato al codice applicaAvo Client Session Ejb
- 65. Business Delegate Un Business Delegate incapsula l’accesso ad un servizio remoto, nascondendo i de4agli dell’implementazione di lookup e del meccanismo di accesso. – Riduce l’accoppiamento tra componenA (il client non conosce la tecnologia del servizio remoto) – Traduce le eccezioni che arrivano dal servizio remoto – Può implementare meccanismi di recovery e caching
- 66. Business Delegate Client «Pojo» BusinessDelegate «Singleton» ServiceLocator - uses - accesses «interface» BusinessService EjbService JmsService - accesses looksup
- 67. Un’archite4ura per il BT Dati BO BO BO BO Client Client Servizio Servizio Delegate Delegate Service Locator
- 68. IntegraAon Tier Pa4ern • Data Access Object • Domain Store • Service Ac7vator • Web Service Broker
- 69. DATA ACCESS OBJECT PoEAA -‐ pag. 117
- 70. DATA ACCESS
- 71. Data Access Object (DAO) DataAccessObject BusinessObject DataPersistence ValueObject encaplsulates uses creates/uses obtains/modifies
- 72. Data Access Object (DAO) Problema • Si vuole separare l’accesso ai daA dal resto dell’applicazione, al fine di ”proteggere” l’applicazione da eventuali modifiche allo strato di persistenza, come ad esempio il cambiamento da un database a un altro. Quello che si vuole è implementare meccanismi per accedere e manipolare i daA in una base di daA riuscendo però a disaccoppiare lo strato di persistenza dal resto dell’applicazione. • Inoltre, si vuole fornire un’API uniforme per un meccanismo di persistenza che sia ada4a a diversi Api di sorgenA di daA (RDBMS, LDAP, OODB, ...)
- 73. Data Access Object (DAO) Problema • E' evidente come una modifica del disposiAvo di persistenza implichi modifiche al codice di tu] gli EJB che vi accedono. • Per confronto si propone lo stesso metodo che uAlizza una classe DAO che incapsula l'uAlizzo di JDBC :
- 74. Data Access Object (DAO) Soluzione • Si usa uno strato intermedio, il Data Access Object (DAO), per astrarre e incapsulare tu] gli accessi al database. Il Data Access Object gesAsce le connessioni con il database per caricare e salvare i daA. • Tale strato è cosAtuito da un insieme di classi dotato di metodi che si occupano di gesAre qualsiasi interazione con la sorgente daA.
- 75. Data Access Object (DAO) Scopo • L'intento del pa4ern DAO (Data Access Object) è di disaccoppiare la logica di business dalla logica di accesso ai daA. • Questo si o]ene spostando la logica di accesso ai daA dai componenA di business ad una classe DAO rendendo gli EJB indipendenA dalla natura del disposiAvo di persistenza. • Questo approccio garanAsce che un eventuale cambiamento del disposiAvo di persistenza non comporA modifiche sui componenA di business.
- 76. Data Access Object (DAO) Funzionamento • L'idea del pa4ern DAO si basa sulla possibilità di concentrare il codice per l'accesso al sistema di persistenza in una classe che si occupa di gesAre la logica di accesso ai daA. • Ad esempio nel caso di un accesso a DBMS si inserisce nel DAO tu4o il codice per effe4uare operazioni sulla base daA, nascondendo le problemaAche JDBC. • Di seguito si riporta il codice di un metodo di business che reperisce i daA dire4amente dal DBMS :
- 77. Accesso dire4o a DBMS import javax.sql.*; import java.sql.* ; . . . public void doSomething(String key) throws SQLException { InitialContext ic = new InitialContext(); DataSource ds = (DataSource) ic.lookup("jdbc/MyDB"); Connection con = ds.getConnection(); String selectStatement = "SELECT NAME FROM ACCOUNT where ID=?"; prepStmt =con.prepareStatement(selectStatement); prepStmt.setString(1, key); ResultSet result = prepStmt.executeQuery(); if (result.next()) { this.name = result.getString(1); } else { throw new SQLException("Name NOT found !"); } }
- 78. Data Access Object (DAO) Implementazione import org.openware.dao.*; public void doSomething (String key) throws MyDataAccessException { MyObjectValue result = this.dao.readAccount(key); if (result != null) { this.name = result.getName(); } else { throw new MyDataAccessException("Name NOT found !"); } }
- 79. Data Access Object (DAO) Soluzione • A parità di funzionalità offerte, l'uAlizzo della classe DAO rende indipendente l'EJB dal DBMS e riuAlizzabile per qualsiasi mezzo di persistenza accessibile con la medesima interfaccia DAO.
- 80. Data Access Object (DAO) StruAura • Il DAO viene invocato dal Business Object e si occupa di effe4uare l'accesso ai daA resAtuendoli all'applicazione. • Le informazioni che il DAO resAtuisce al Business Object sono ogge] generici ( indipendenA dal disposiAvo di persistenza ) e le eventuali eccezioni specifiche della risorsa daA sono mascherate ( wrapped ) in eccezioni generiche di Apo applicaAvo.
- 81. Data Access Object (DAO) StruAura ValueObject BusinessObject DataAccessObject DataPersistence creates/uses obtains/modifies uses encaplsulates
- 82. Data Transfer Object (DTO)
- 83. Data Access Object (DAO)
- 84. Data Access Object (DAO) Implementazione • Il client crea l'EJB invocando il metodo create sull'istanza della Home Interface recuperata mediante le operazioni di lookup e narrow. Account account = accountHome.create("007", "Java Earl", ”earl@hero.com", 0);
- 85. Data Access Object (DAO) Class Diagram org.openware.paAern.dao.MyDao org.openware.paAern.dao.MyDaoImpl ...paAern.excep<on.DAOExpe<on java.lang.Excep<on
- 86. Data Access Object (DAO) Implementazione • Il container invoca il metodo ejbCreate che si avvale dell'istanza dao creata nel metodo setEntityContext : public void setEntityContext(EntityContext ctx) { . . . try { this.dao = new MyDaoImpl("java:comp/env/jdbc/OpenwareDataBase"); } catch (NamingException e) { . . . } }
- 87. Data Access Object (DAO) Implementazione • Allo sviluppatore dell'EJB è reso trasparente l'accesso alla tabella del DBMS mediante JDBC, infa] si limita a chiamare il metodo insertAccount del DAO. • Si noA come nel codice del bean non si ha nessun riferimento ai package sql (java.sql e javax.sql) bensì vengono importate l'interfaccia MyDao, la classe concreta MyDaoImpl e l'eccezione DAOException.
- 88. Data Access Object (DAO) Import org.openware.pattern.dao.MyDao; import org.openware.pattern.dao.MyDaoImpl; import org.openware.pattern.exception.DAOException; public AccountPK ejbCreate(String id, String name, String address, double balance) throws CreateException { . . . try { // Use DAO to insert account into the underlaying layer AccountPK pk = new AccountPK(id); this.dao.insertAccount(pk, name, address, balance); this.name = name; this.email = address; this.balance = balance; return pk; } catch (DAOException e) { . . . } }
- 89. Data Access Object (DAO) public class MyDaoImpl implements MyDao { public int insertAccount(AccountPK pk, String name, String address, double balance) throws DAOException { Connection con = null; PreparedStatement stmt = null; try { con = dataSource.getConnection(); stmt = con.prepareStatement( "INSERT INTO OPWR_ACCOUNT(ID, NAME, ADDRESS, BALANCE) VALUES (?, ?, ?, ?)"); stmt.setString(1, pk.id); stmt.setString(2, name); stmt.setString(3, address); stmt.setDouble(4, balance); int res = stmt.executeUpdate(); return res; } catch(SQLException sqle) { throw new DAOException(sqle.getMessage()); } finally { closeResources(con, stmt, null); } }
- 90. Data Access Object (DAO) public class MyDaoImpl implements MyDao { public int insertAccount(AccountPK pk, String name, String address, double balance) throws DAOException { Connection con = null; PreparedStatement stmt = null; try { con = dataSource.getConnection(); stmt = con.prepareStatement( "INSERT INTO OPWR_ACCOUNT(ID, NAME, ADDRESS, BALANCE) VALUES (?, ?, ?, ?)"); stmt.setString(1, pk.id); stmt.setString(2, name); stmt.setString(3, address); stmt.setDouble(4, balance); int res = stmt.executeUpdate(); return res; } catch(SQLException sqle) { throw new DAOException(sqle.getMessage()); } finally { closeResources(con, stmt, null); } } Il metodo insertAccount effe4ua l'accesso fisico alla tabella del DBMS mediante JDBC.
- 91. Data Access Object (DAO) public class MyDaoImpl implements MyDao { public int insertAccount(AccountPK pk, String name, String address, double balance) throws DAOException { Connection con = null; PreparedStatement stmt = null; try { con = dataSource.getConnection(); stmt = con.prepareStatement( "INSERT INTO OPWR_ACCOUNT(ID, NAME, ADDRESS, BALANCE) VALUES (?, ?, ?, ?)"); stmt.setString(1, pk.id); stmt.setString(2, name); stmt.setString(3, address); stmt.setDouble(4, balance); int res = stmt.executeUpdate(); return res; } catch(SQLException sqle) { throw new DAOException(sqle.getMessage()); } finally { closeResources(con, stmt, null); } } Il metodo insertAccount effe4ua l'accesso fisico alla tabella del DBMS mediante JDBC.
- 92. Data Access Object (DAO) public class MyDaoImpl implements MyDao { public int insertAccount(AccountPK pk, String name, String address, double balance) throws DAOException { Connection con = null; PreparedStatement stmt = null; try { con = dataSource.getConnection(); stmt = con.prepareStatement( "INSERT INTO OPWR_ACCOUNT(ID, NAME, ADDRESS, BALANCE) VALUES (?, ?, ?, ?)"); stmt.setString(1, pk.id); stmt.setString(2, name); stmt.setString(3, address); stmt.setDouble(4, balance); int res = stmt.executeUpdate(); return res; } catch(SQLException sqle) { throw new DAOException(sqle.getMessage()); } finally { closeResources(con, stmt, null); } } Le SQLException vengano "wrappate" in eccezioni applicaAve DaoException.
- 93. Data Access Object (DAO) Implementazione • Il funzionamento degli altri metodi è analogo a quanto appena spiegato : Client EJB AccountDAO SQL create ejbCreate insertAccount INSERT
- 94. Data Access Object (DAO) Implementazione • Il funzionamento degli altri metodi è analogo a quanto appena spiegato : Client EJB AccountDAO SQL create ejbCreate insertAccount INSERT findByPrimaryKey ejbFindByPrimaryKey accountExists SELECT
- 95. Data Access Object (DAO) Implementazione • Il funzionamento degli altri metodi è analogo a quanto appena spiegato : Client EJB AccountDAO SQL create ejbCreate insertAccount INSERT findByPrimaryKey ejbFindByPrimaryKey accountExists SELECT remove ejbRemove deleteAccount REMOVE
- 96. Data Access Object (DAO) Implementazione • Il funzionamento degli altri metodi è analogo a quanto appena spiegato : Client EJB AccountDAO SQL create ejbCreate insertAccount INSERT findByPrimaryKey ejbFindByPrimaryKey accountExists SELECT remove ejbRemove deleteAccount REMOVE load ejbLoad readAccount SELECT
- 97. Data Access Object (DAO) Implementazione • Il funzionamento degli altri metodi è analogo a quanto appena spiegato : Client EJB AccountDAO SQL create ejbCreate insertAccount INSERT findByPrimaryKey ejbFindByPrimaryKey accountExists SELECT remove ejbRemove deleteAccount REMOVE load ejbLoad readAccount SELECT store ejbStore updateAccount UPDATE
- 98. Data Access Object (DAO) Un caso d’uso • Il pa4ern DAO si inserisce in quei contesA in cui un accesso a componenA di persistenza deve essere reso trasparente all'applicazione. • L'esempio proposto rappresenta il caso di una banca che ha la necessità di memorizzare le informazioni del conto corrente utente su un disposiAvo di persistenza. • In una situazione di questo Apo è uAle che gli EJB si interfaccino con il DB con un layer di disaccoppiamento garanAto dal DAO.
- 99. Data Access Object (DAO) Un caso d’uso org.openware.pattern.ejb.session org.openware.pattern.ejb.entity org.openware.pattern.dao PersistenceModule
- 100. Data Access Object (DAO)
- 101. Data Access Object (DAO) Conseguenze • Alcune delle conseguenze dell’applicazione di tale pa4ern sono: – abilita la trasparenza – rende possibile una più facile migrazione verso altri storage engine – fornisce una visione object-‐oriented e incapsula gli schemi del database – organizza tu4o il codice che si occupa dell’accesso ai daA in un layer separato
- 102. Data Access Object Nelle applicazioni J2ee è spesso necessario integrare o migrare sistemi legacy operanA con diverse tecnologie • RDBMS, OODB • LDAP • Flat files, XML, ... • CICS, IMS, ... Codificare l’integrazione con quesA sistemi nel codice applicaAvo o nei business object rende l’applicazione poco flessibile, espandibile e riusabile
- 103. Data Access Object DB Data Access Object Data Access Object Integration Tier LDAP Client Client Utilizzare un Data Access Object (DAO) che mascheri e incapsuli la logica di accesso ai dati
- 104. Data Access Object • E’ applicabile in ogni occasione in cui l’applicazione debba accedere a dei daA • Disaccoppia la logica di business da quella di persistenza • Facilita, dopo l’integrazione, il processo di migrazione • Strategie Apiche di uAlizzo: • con business object POJO • in combinazione con EJB BMP • per l’integrazione con ambienA parAcolari (IMS, LDAP, file)
- 105. Data Access Object: responsabilità • Crea una connessione al data source • Non gesAsce dire4amente la transazione ma è in grado di partecipare ad una transazione • E’ responsabile del marshalling e unmarshalling tra ogge] di business e daA persistenA
- 106. Data Access Object: implementazione Client DataAccessObject + create ( ) + read ( ) + update ( ) + delete ( ) DataSource «TransferObject» Data ResultSet - uses - accesses - creates - uses - creates - creates/uses
- 107. Data Access Object: implementazione Client DAOFactory + getDaoAlpha ( ) + getDaoBeta ( ) + getDaoGamma ( ) MySqlDAOFactory + getDaoAlpha ( ) + getDaoBeta ( ) + getDaoGamma ( ) Hypersonic DAOFactory + getDaoAlpha ( ) + getDaoBeta ( ) + getDaoGamma ( ) - uses - delegates - delegates MySqlAlphaDAO HypersonicSqlAlphaDao - creates - uses - creates - uses
- 108. Passato, Presente e Futuro ... dei paAern ... • Studio delle applicazioni esistenA • Best prac7ce per la proge4azione • Model Driven Architecture (MDA) e pa4ern
- 109. Referenze hHp://www.corej2eepaHerns.com Alur, Crupi, Malks, Core J2ee Patterns – Best Practices and Design Strategies, 2nd edition, Prentice Hall, 2003