Your SlideShare is downloading. ×
Design Patterns - Enterprise Patterns (part 2)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Design Patterns - Enterprise Patterns (part 2)

485
views

Published on

Design Patterns - Enterprise Patterns (part 2) …

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

Published in: Software

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
485
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
20
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. fabio.armani  
  • 2. Overview   •  Analysis  pa4erns   •  Architectural  pa4erns   •  Design  pa4erns   •  Enterprise  pa4erns   •  GRASP  pa4erns   •  ImplementaAon  pa4erns   •  J2EE  Core  pa4erns   •  SCM  pa4erns  
  • 3. ENTERPRISE  PATTERN  
  • 4. Enterprise  Pa4erns   •  Pa4erns  of  Enterprise  ApplicaAon  Architecture   •  Core  J2EE  Pa4erns   •  IntegraAon  Pa4erns  
  • 5. Enterprise  Pa4erns  >  books  
  • 6. Core  J2EE  Pa4erns   •  PresentaAon  Tier   •  Business  Tier   •  IntegraAon  Tier  
  • 7. Core  J2EE  Pa4erns   •  PresentaAon  Tier   –  ApplicaAon  Controller   –  Composite  View   –  Context  Object   –  Dispatcher  View   –  Front  Controller   –  IntercepAng  Filter   –  Service  To  Worker   –  View  Helper  
  • 8. 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  
  • 9. 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  
  • 10. PresentaAon  Tier  Pa4ern   •  Front  Controller   •  View  Helper   •  Composite  View   •  Dispatcher  View  
  • 11. 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  
  • 12. 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
  • 13. DATA  TRANSFER  OBJECT   PoEAA  -­‐  pag.  117  
  • 14. DATA  TRANSFER  
  • 15. 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).  
  • 16. 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.  
  • 17. Data  Transfer  Object  (DTO)      Presenta<on      Business      Data  Access  
  • 18. 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).  
  • 19. Data  Transfer  Object  (DTO)   Scopo  
  • 20. Data  Transfer  Object  (DTO)   Soluzione  
  • 21. 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.  
  • 22. 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.    
  • 23. 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.    
  • 24. Data  Transfer  Object  (DTO)      Presenta<on      Business      Data  Access   DTO   DTO  
  • 25. Data  Transfer  Object  (DTO)   Soluzione  
  • 26. 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.  
  • 27. Data  Transfer  Object  (DTO)   StruAura  
  • 28. Data  Transfer  Object  (DTO)   Esempio:  interazione  senza  uAlizzo  DTO  
  • 29. Data  Transfer  Object  (DTO)   Esempio:  interazione  con  server  mediante  DTO  
  • 30. 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.  
  • 31. 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.  
  • 32. 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.  
  • 33. 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.  
  • 34. 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; } }      
  • 35. 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.  
  • 36. 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());    } }    
  • 37. Data  Transfer  Object  (DTO)   Sequence  diagram  
  • 38. Data  Transfer  Object  (DTO)  
  • 39. 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    
  • 40. BUSINESS  OBJECT   PoEAA  -­‐  pag.  117  
  • 41. BUSINESS  OBJECT  
  • 42. 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.    
  • 43. 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  
  • 44. 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
  • 45. 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  
  • 46. 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.  
  • 47. 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  
  • 48. 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  
  • 49. 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    
  • 50. APPLICATION  SERVICE   PoEAA  -­‐  pag.  117  
  • 51. 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  
  • 52. 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
  • 53. 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  
  • 54. 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  
  • 55. ApplicaAon  Service   Command  Strategy   Client ApplicationService ServiceFacade «Pojo» Helper ApplicationController - invokes CommandFactory Command + execute ( ) - uses - invokes - creates - invokes
  • 56. SERVICE  LOCATOR   PoEAA  -­‐  pag.  117  
  • 57. 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  
  • 58. 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  
  • 59. Service  Locator   Client «Singleton» ServiceLocator- uses 1 1..* TargetService - _looksup - accesses Cache - mantains - caches InitialContext- creates/uses RegistryService - refers - resolves Una implementazione tipica
  • 60. BUSINESS  DELEGATE   PoEAA  -­‐  pag.  117  
  • 61. 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  
  • 62. 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  
  • 63. Business  Delegate   Client «Pojo» BusinessDelegate «Singleton» ServiceLocator - uses - accesses «interface» BusinessService EjbService JmsService - accesses looksup
  • 64. Un’archite4ura  per  il  BT   Dati BO   BO   BO   BO   Client   Client   Servizio   Servizio   Delegate   Delegate   Service     Locator  
  • 65. IntegraAon  Tier  Pa4ern   •  Data  Access  Object   •  Domain  Store   •  Service  Ac7vator   •  Web  Service  Broker  
  • 66. DATA  ACCESS  OBJECT   PoEAA  -­‐  pag.  117  
  • 67. DATA  ACCESS  
  • 68. Data  Access  Object  (DAO)   DataAccessObject   BusinessObject   DataPersistence   ValueObject   encaplsulates  uses   creates/uses   obtains/modifies  
  • 69. 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,  ...)      
  • 70. 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  :  
  • 71. 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.    
  • 72. 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.  
  • 73. 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  :  
  • 74. 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 !");    } }
  • 75. 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 !");    } }    
  • 76. 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.  
  • 77. 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.      
  • 78. Data  Access  Object  (DAO)   StruAura   ValueObject   BusinessObject   DataAccessObject   DataPersistence   creates/uses   obtains/modifies   uses   encaplsulates  
  • 79. Data  Transfer  Object  (DTO)  
  • 80. Data  Access  Object  (DAO)  
  • 81. 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);
  • 82. 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  
  • 83. 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) {      . . .    } }
  • 84. 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.  
  • 85. 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) {       . . .    } }      
  • 86. 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);    } }      
  • 87. 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.  
  • 88. 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.  
  • 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);    } }       Le  SQLException  vengano  "wrappate"  in  eccezioni   applicaAve  DaoException.  
  • 90. Data  Access  Object  (DAO)   Implementazione   •  Il  funzionamento  degli  altri  metodi  è  analogo  a  quanto   appena  spiegato  :   Client   EJB   AccountDAO   SQL   create ejbCreate insertAccount INSERT
  • 91. 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
  • 92. 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
  • 93. 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
  • 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 remove ejbRemove deleteAccount REMOVE load ejbLoad readAccount SELECT store ejbStore updateAccount UPDATE
  • 95. 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.  
  • 96. Data  Access  Object  (DAO)   Un  caso  d’uso   org.openware.pattern.ejb.session org.openware.pattern.ejb.entity org.openware.pattern.dao PersistenceModule
  • 97. Data  Access  Object  (DAO)  
  • 98. 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      
  • 99. 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  
  • 100. 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
  • 101. 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)  
  • 102. 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  
  • 103. Data  Access  Object:  implementazione   Client DataAccessObject + create ( ) + read ( ) + update ( ) + delete ( ) DataSource «TransferObject» Data ResultSet - uses - accesses - creates - uses - creates - creates/uses
  • 104. 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
  • 105. Passato,  Presente  e  Futuro   ...  dei  paAern  ...     •  Studio  delle  applicazioni  esistenA   •  Best  prac7ce  per  la  proge4azione   •  Model  Driven  Architecture  (MDA)  e  pa4ern  
  • 106. Referenze   hHp://www.corej2eepaHerns.com   Alur, Crupi, Malks, Core J2ee Patterns – Best Practices and Design Strategies, 2nd edition, Prentice Hall, 2003