View
537
Download
3
Category
Preview:
DESCRIPTION
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
Citation preview
fabio.armani
Overview
• Analysis pa4erns • Architectural pa4erns • Design pa4erns • Enterprise pa4erns • GRASP pa4erns • ImplementaAon pa4erns • J2EE Core pa4erns • SCM pa4erns
ENTERPRISE PATTERN
Enterprise Pa4erns • Pa4erns of Enterprise ApplicaAon Architecture • Core J2EE Pa4erns • IntegraAon Pa4erns
Enterprise Pa4erns > books
Core J2EE Pa4erns • PresentaAon Tier • Business Tier • IntegraAon Tier
Core J2EE Pa4erns • PresentaAon Tier
– ApplicaAon Controller – Composite View – Context Object – Dispatcher View – Front Controller – IntercepAng Filter – Service To Worker – View Helper
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
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
PresentaAon Tier Pa4ern
• Front Controller • View Helper • Composite View • Dispatcher View
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
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
DATA TRANSFER OBJECT PoEAA -‐ pag. 117
DATA TRANSFER
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).
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 so\ware.
• 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.
Data Transfer Object (DTO)
Presenta<on
Business
Data Access
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).
Data Transfer Object (DTO)
Scopo
Data Transfer Object (DTO)
Soluzione
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.
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.
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.
Data Transfer Object (DTO)
Presenta<on
Business
Data Access
DTO
DTO
Data Transfer Object (DTO)
Soluzione
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.
Data Transfer Object (DTO)
StruAura
Data Transfer Object (DTO)
Esempio: interazione senza uAlizzo DTO
Data Transfer Object (DTO)
Esempio: interazione con server mediante DTO
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.
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.
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.
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.
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; }
}
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.
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()); } }
Data Transfer Object (DTO)
Sequence diagram
Data Transfer Object (DTO)
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
BUSINESS OBJECT PoEAA -‐ pag. 117
BUSINESS OBJECT
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.
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
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
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
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.
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
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
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
APPLICATION SERVICE PoEAA -‐ pag. 117
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
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
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
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
ApplicaAon Service
Command Strategy
Client
ApplicationService
ServiceFacade «Pojo»Helper
ApplicationController- invokes
CommandFactory
Command
+ execute ( )
- uses
- invokes
- creates
- invokes
SERVICE LOCATOR PoEAA -‐ pag. 117
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
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
Service Locator
Client «Singleton»ServiceLocator- uses
1
1..*
TargetService
- _looksup
- accesses
Cache
- mantains
- caches
InitialContext- creates/uses
RegistryService
- refers
- resolves
Una implementazione tipica
BUSINESS DELEGATE PoEAA -‐ pag. 117
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
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
Business Delegate
Client«Pojo»
BusinessDelegate
«Singleton»ServiceLocator
- uses
- accesses«interface»
BusinessService
EjbService JmsService
- accesses
looksup
Un’archite4ura per il BT
Dati
BO
BO
BO
BO
Client
Client
Servizio
Servizio
Delegate
Delegate
Service Locator
IntegraAon Tier Pa4ern
• Data Access Object • Domain Store • Service Ac7vator • Web Service Broker
DATA ACCESS OBJECT PoEAA -‐ pag. 117
DATA ACCESS
Data Access Object (DAO)
DataAccessObject
BusinessObject DataPersistence
ValueObject
encaplsulates uses
creates/uses obtains/modifies
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, ...)
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 :
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.
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.
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 :
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 !"); } }
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 !"); } }
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.
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.
Data Access Object (DAO)
StruAura
ValueObject
BusinessObject DataAccessObject DataPersistence
creates/uses
obtains/modifies
uses encaplsulates
Data Transfer Object (DTO)
Data Access Object (DAO)
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);
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
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) { . . . } }
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.
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) { . . . } }
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); } }
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.
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.
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.
Data Access Object (DAO)
Implementazione • Il funzionamento degli altri metodi è analogo a quanto
appena spiegato :
Client EJB AccountDAO SQL
create ejbCreate insertAccount INSERT
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
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
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
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
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.
Data Access Object (DAO)
Un caso d’uso
org.openware.pattern.ejb.session
org.openware.pattern.ejb.entity
org.openware.pattern.dao PersistenceModule
Data Access Object (DAO)
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
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
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
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)
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
Data Access Object: implementazione
Client DataAccessObject
+ create ( )+ read ( )+ update ( )+ delete ( )
DataSource
«TransferObject»Data
ResultSet
- uses - accesses
- creates- uses
- creates- creates/uses
Data Access Object: implementazione
Client DAOFactory
+ getDaoAlpha ( )+ getDaoBeta ( )+ getDaoGamma ( )
MySqlDAOFactory
+ getDaoAlpha ( )+ getDaoBeta ( )+ getDaoGamma ( )
HypersonicDAOFactory
+ getDaoAlpha ( )+ getDaoBeta ( )+ getDaoGamma ( )
- uses
- delegates
- delegates
MySqlAlphaDAO
HypersonicSqlAlphaDao
- creates
- uses
- creates
- uses
Passato, Presente e Futuro
... dei paAern ... • Studio delle applicazioni esistenA • Best prac7ce per la proge4azione • Model Driven Architecture (MDA) e pa4ern
Referenze
hHp://www.corej2eepaHerns.com
Alur, Crupi, Malks, Core J2ee Patterns – Best Practices and Design Strategies, 2nd edition, Prentice Hall, 2003
Recommended