SlideShare a Scribd company logo

Design Patterns - Enterprise Patterns (part 2)

Fabio Armani
Fabio Armani

Il documento discute varie architetture e design pattern, con particolare attenzione ai Data Transfer Objects (DTO), che consentono di trasferire dati in modo efficiente tra vari strati di un'applicazione distribuita. Viene evidenziato il ruolo dei Business Objects e dei Data Access Objects nel separare la logica di business dall'infrastruttura di persistenza, favorendo la riusabilità e la manutenibilità del codice. Infine, si parla dell'importanza di pattern come il Service Locator e il Business Delegate per semplificare l'accesso ai servizi remoti.

Software
1 of 109
Downloaded 51 times
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
Design Patterns - Enterprise Patterns (part 2)
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  
Design Patterns - Enterprise Patterns (part 2)
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  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.  
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.  
Design Patterns - Enterprise Patterns (part 2)
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 ( ) Hypersonic DAOFactory + 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

More Related Content

Viewers also liked (20)

PDF
Lean Agile Adoption Enterprise Challenges - XP 2012
Fabio Armani
 
PDF
The Tao of Agile - XP2012
Fabio Armani
 
PDF
Behavior Driven Development - WPC 2011
Fabio Armani
 
PDF
Shape Shift - XP 2009
Fabio Armani
 
PDF
Lean Agile Development - a war story (Better Software 2010)
Fabio Armani
 
PDF
Mapping the Value (Agilia Budapest 2016)
Fabio Armani
 
PDF
Lean Agile Contracts - iad 2012
Fabio Armani
 
PDF
Back to Agile - Codemotion 2013
Fabio Armani
 
PDF
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Fabio Armani
 
PPTX
Scaling lean agile agile prage 2014 (armani)
Fabio Armani
 
PDF
Scrum buts » but Scrum - which is worse?
Fabio Armani
 
PDF
Agile soft skills suitecase - iad 2011
Fabio Armani
 
PDF
Lean UX - Integrated Teams
Fabio Armani
 
PDF
Agile requirements - alla ricerca del filo rosso (iad 2013)
Fabio Armani
 
PDF
User Story Mapping - mini iad 2014 (Armani, Rodriguez)
Fabio Armani
 
PDF
User Stories Writing - Codemotion 2013
Fabio Armani
 
PDF
User Stories writing - Bettersoftware 2012
Fabio Armani
 
PDF
Impact Mapping LEGO Game - Agile Business Day 2016
Fabio Armani
 
PPTX
A Practical Guide to Domain Driven Design: Presentation Slides
thinkddd
 
PDF
データベース技術の羅針盤
Yoshinori Matsunobu
 
Lean Agile Adoption Enterprise Challenges - XP 2012
Fabio Armani
 
The Tao of Agile - XP2012
Fabio Armani
 
Behavior Driven Development - WPC 2011
Fabio Armani
 
Shape Shift - XP 2009
Fabio Armani
 
Lean Agile Development - a war story (Better Software 2010)
Fabio Armani
 
Mapping the Value (Agilia Budapest 2016)
Fabio Armani
 
Lean Agile Contracts - iad 2012
Fabio Armani
 
Back to Agile - Codemotion 2013
Fabio Armani
 
Scrumban a Methodology Fusion - Bettersoftware & Codemotion 2011
Fabio Armani
 
Scaling lean agile agile prage 2014 (armani)
Fabio Armani
 
Scrum buts » but Scrum - which is worse?
Fabio Armani
 
Agile soft skills suitecase - iad 2011
Fabio Armani
 
Lean UX - Integrated Teams
Fabio Armani
 
Agile requirements - alla ricerca del filo rosso (iad 2013)
Fabio Armani
 
User Story Mapping - mini iad 2014 (Armani, Rodriguez)
Fabio Armani
 
User Stories Writing - Codemotion 2013
Fabio Armani
 
User Stories writing - Bettersoftware 2012
Fabio Armani
 
Impact Mapping LEGO Game - Agile Business Day 2016
Fabio Armani
 
A Practical Guide to Domain Driven Design: Presentation Slides
thinkddd
 
データベース技術の羅針盤
Yoshinori Matsunobu
 

Similar to Design Patterns - Enterprise Patterns (part 2) (14)

PDF
EE Incremental Store
firenze-gtug
 
PPTX
Entity Framework 4 vs NHibernate 3
Martino Bordin
 
PDF
ORM - Introduzione
Alessandro Forte
 
PPTX
Entity Framework 6 for developers, Code-First!
Michael Denny
 
PPTX
Pomeriggio Entity Framework - Code First
DomusDotNet
 
PPSX
Entity Framework 4.0 vs NHibernate
Manuel Scapolan
 
PPT
Slides marcosabatini
Marco Sabatini
 
PPTX
Wcf data services
Salvatore Sorrentino
 
PPTX
Advanced ef code first 5.0 - EF@work
DomusDotNet
 
PPTX
WeWantWeb - WCF Data Services
DomusDotNet
 
PPT
Loosely Coupled Complexity - Unleash the power of your domain model
Francesca1980
 
PDF
Cerved - The Italian Business Graph: a Story of Tech & data-driven Innovation
Neo4j
 
PPT
Corba
Francesco Meschia
 
PPTX
Deep diving C# 4 (Raffaele Rialdi)
DotNetMarche
 
EE Incremental Store
firenze-gtug
 
Entity Framework 4 vs NHibernate 3
Martino Bordin
 
ORM - Introduzione
Alessandro Forte
 
Entity Framework 6 for developers, Code-First!
Michael Denny
 
Pomeriggio Entity Framework - Code First
DomusDotNet
 
Entity Framework 4.0 vs NHibernate
Manuel Scapolan
 
Slides marcosabatini
Marco Sabatini
 
Wcf data services
Salvatore Sorrentino
 
Advanced ef code first 5.0 - EF@work
DomusDotNet
 
WeWantWeb - WCF Data Services
DomusDotNet
 
Loosely Coupled Complexity - Unleash the power of your domain model
Francesca1980
 
Cerved - The Italian Business Graph: a Story of Tech & data-driven Innovation
Neo4j
 
Corba
Francesco Meschia
 
Deep diving C# 4 (Raffaele Rialdi)
DotNetMarche
 
Ad

More from Fabio Armani (17)

PDF
Agile Music from the Trenches
Fabio Armani
 
PDF
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Fabio Armani
 
PDF
Product Values - Ethical Considerations - ver 1.4 (no video).pdf
Fabio Armani
 
PDF
Surfing on the Edge of Chaos
Fabio Armani
 
PDF
Agile marketing - beyond it 2021
Fabio Armani
 
PDF
Agile Myths and Pitfalls - 2020 (ver 0.8)
Fabio Armani
 
PDF
Appreciative Inquiry - an overview
Fabio Armani
 
PPTX
Appreciative Inquiry - an introduction
Fabio Armani
 
PDF
Mapping the Change - final
Fabio Armani
 
PDF
Manifiesto de Mañana Programming
Fabio Armani
 
PDF
From Manana Programming to Zen Delivery (final) - 2019
Fabio Armani
 
PDF
Human Side of Agile (Agile Venture 2019)
Fabio Armani
 
PDF
Psychological Safety - ABD19
Fabio Armani
 
PDF
Enterprise lean agile 2018 challenges ver 0.3
Fabio Armani
 
PPTX
Business Agility 2017 (final)
Fabio Armani
 
PDF
Lean Change Management (part II) - IAD 2014
Fabio Armani
 
PDF
Lean Change Management (part I) - IAD 2014
Fabio Armani
 
Agile Music from the Trenches
Fabio Armani
 
Alien eXperience - FuffaDay 2022 (Fabio Armani & Virginia Capoluongo)
Fabio Armani
 
Product Values - Ethical Considerations - ver 1.4 (no video).pdf
Fabio Armani
 
Surfing on the Edge of Chaos
Fabio Armani
 
Agile marketing - beyond it 2021
Fabio Armani
 
Agile Myths and Pitfalls - 2020 (ver 0.8)
Fabio Armani
 
Appreciative Inquiry - an overview
Fabio Armani
 
Appreciative Inquiry - an introduction
Fabio Armani
 
Mapping the Change - final
Fabio Armani
 
Manifiesto de Mañana Programming
Fabio Armani
 
From Manana Programming to Zen Delivery (final) - 2019
Fabio Armani
 
Human Side of Agile (Agile Venture 2019)
Fabio Armani
 
Psychological Safety - ABD19
Fabio Armani
 
Enterprise lean agile 2018 challenges ver 0.3
Fabio Armani
 
Business Agility 2017 (final)
Fabio Armani
 
Lean Change Management (part II) - IAD 2014
Fabio Armani
 
Lean Change Management (part I) - IAD 2014
Fabio Armani
 
Ad

Design Patterns - Enterprise Patterns (part 2)

  • 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  
  • 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  
  • 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  
  • 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  
  • 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  
  • 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  
  • 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", ”[email protected]", 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