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
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
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.
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).
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.
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.
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.
38.
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());
}
}
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
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
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
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
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
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.
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
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
108. Passato,
Presente
e
Futuro
...
dei
paAern
...
• Studio
delle
applicazioni
esistenA
• Best
prac7ce
per
la
proge4azione
• Model
Driven
Architecture
(MDA)
e
pa4ern