Design Patterns - enterprise patterns (part I)

1,802 views

Published on

This set of design patterns are related to Enterprise Patterns. In it you can find, J2EE, Presentation, Business & Integration Patterns (such as: ApplicaCon Controller, Data Transfer Object (DTO), Business Object (BO) & Data Access Object (DAO) among others ...)

Published in: Software
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,802
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
50
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide

Design Patterns - enterprise patterns (part I)

  1. 1. ENTERPRISE PATTERNS fabio.armani
  2. 2. fabio.armani
  3. 3. Overview • Analysis patterns • Architectural patterns • Design patterns • Enterprise patterns • GRASP patterns • Implementation patterns • J2EE Core patterns • SCM patterns
  4. 4. ENTERPRISE PATTERNS
  5. 5. Enterprise Patterns • Patterns of Enterprise Application Architecture • Core J2EE Patterns • Integration Patterns
  6. 6. Enterprise Patterns > books
  7. 7. Core J2EE Patterns • Presentation Tier • Business Tier • Integration Tier
  8. 8. Core J2EE Patterns • Presentation Tier – Application Controller – Composite View – Context Object – Dispatcher View – Front Controller – Intercepting Filter – Service To Worker – View Helper
  9. 9. Core J2EE 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
  10. 10. Core J2EE 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
  11. 11. Presentation Tier Pattern • Front Controller • View Helper • Composite View • Dispatcher View
  12. 12. FRONT CONTROLLER PoEAA - pag. 117
  13. 13. FRONT CONTROLLER
  14. 14. FRONT CONTROLLER
  15. 15. Front Controller Descrizione • Consente di gestire il mapping logico delle risorse
  16. 16. Front Controller Problema • Si vuole fornire un punto di accesso centralizzato per la gestione delle richieste al livello dello strato di presentazione, in modo da sparare la logica di presentazione da quella di processamento delle richieste stesse. • Inoltre si vuole evitare di avere del codice duplicato e si vuole applicare una logica comune a più richieste.
  17. 17. Front Controller Soluzione • Si utilizza un Front Controller come punto di accesso iniziale per gestire tutte le richieste connesse tra loro. • Il Front Controller centralizza la logica di controllo che dovrebbe altrimenti essere replicata per ogni richiesta.
  18. 18. Front Controller Avoid: • Physical Resource Mapping • Unhandled Mapping in Multyplexed Resource Mapping strategy • Logging of Arbitrary HTTTP Parameters • Duplicating Common Logic Across Multiple Front Controllers Use to Implement: • Logical Resource Mapping • Session Management • Audit Logging Avoid: • Invoking Commands Without Sufficient Authorization
  19. 19. Front Controller Struttura
  20. 20. Front Controller
  21. 21. Front Controller
  22. 22. Front Controller
  23. 23. Front Controller Partecipanti • Front controller – Oggetto Singleton che intercetta tutte le richieste ed esegue le funzioni comuni. • Page controllers (o Actions) – Elaborano l’input dell'utente, aggiornano il modello e scelgono le viste. • Model – Memorizza i dati di stato dell’applicazione. • Views – Trasformano i dati del modello in una forma appropriata per la visualizzazione all'utente.
  24. 24. Front Controller Conseguenze • Le conseguenze che derivano dall’utilizzo di tale pattern sono: – centralizzazione del controllo – miglioramento della riusabilità – miglioramento della manutenibilità – separazione dei ruoli all’interno dell’applicazione
  25. 25. Front Controller
  26. 26. Front Controller
  27. 27. VIEW HELPER PoEAA - pag. 117
  28. 28. VIEW HELPER
  29. 29. View Helper Descrizione • Consente la definizione di una famiglia d’algoritmi, incapsula ognuno e gli fa intercambiabili fra di loro. • Questo permette modificare gli algoritmi in modo indipendente dai clienti che fanno uso di essi.
  30. 30. View Helper Problema • Si vuole separare la vista dalla sua logica di elaborazione.
  31. 31. View Helper Forze • Volete utilizzare delle viste (view) basate su template, come le JSP. • Volete evitare di inserire della logica di programmazione nelle viste. • Volete separare la logica di programmazione dalle viste per facilitare la divisione del lavoro tra sviluppatori software e sviluppatori di pagine web.
  32. 32. View Helper Soluzione • L’utilizzo delle View per incapsulare il codice di formattazione e degli Helper per incapsulare la logica di elaborazione delle view. • Una View delega le proprie responsabilità di elaborazione alle sue classi di supporto (Helper), implementate come POJO, custom tag o file tag. • Gli Helper fungono da adattatori tra la vista e il modello, ed eseguono le elaborazioni relative alla logica di formattazione, (come la generazione di una tabella HTML).
  33. 33. View Helper Avoid: • XSLT and Xpath Vulnerabilities • Unencoded User Supplied Data Use to Implement: • Output Encoding in Custom Tag Helper Class diagram
  34. 34. View Helper Sequence diagram
  35. 35. View Helper
  36. 36. View Helper Strategie • Template-Based View Strategy • Controller-Based View Strategy • JavaBean Helper Strategy • Custom Tag Helper Strategy • Tag File Helper Strategy • Business Delegate as Helper Strategy
  37. 37. View Helper Conseguenze • Migliora il partizionamento dell’applicazione, il riutilizzo e la manutenibilità • Migliora la separazione dei ruoli • facilita il testing • L’utilizzo dell’Helper rspecchie gli scriptlet
  38. 38. Business Tier Pattern • Data Transfer Object • Business Object • Service Locator • Application Service • Business Delegate • Value List Handler • Session Facade • Composite Entity • Transfer Object • Transfer Object Assembler
  39. 39. Business Tier Pattern • Data Transfer Object • Business Object • Service Locator • Application Service • Business Delegate • Value List Handler • Session Facade • Composite Entity • Transfer Object • Transfer Object Assembler Ejb Pattern
  40. 40. DATA TRANSFER OBJECT PoEAA - pag. 117
  41. 41. DATA TRANSFER
  42. 42. Data Transfer Object (DTO) Descrizione • Il DTO (Data Transfer Object ) è un pattern che risulta essere molto utile lavorando in applicazioni tipicamente distribuite, in cui la maggior parte delle chiamate e delle invocazioni è fatta in maniera remota (macchine diverse).
  43. 43. Data Transfer Object (DTO) Descrizione • L' Oggetto di Trasferimento Dati o Data Transfer Object (in sigla DTO) è un design pattern usato per trasferire dati tra sottosistemi di un'applicazione software. • I DTO sono spesso usati in congiunzione con gli oggetti accesso dati per recuperare i suddetti da una base di dati. • La differenza tra gli oggetti di trasferimento dati e gli oggetti business o gli oggetti d'accesso dati è che un DTO non ha alcun comportamento se non di archiviare e recuperare i suoi dati.
  44. 44. Data Transfer Object (DTO) Presentation Business Data Access
  45. 45. Data Transfer Object (DTO) Scopo • Una buona organizzazione di una architettura enterprise è costituita normalmente di un stratificazione basata almeno sui seguenti livelli: – strato client applicativo (esempio le actions di una applicazione Struts), – strato client di comunicazione con il server (BD), – strato server di session façade, – uno o più strati applicativi di sessione, strato data model (entity beans).
  46. 46. Data Transfer Object (DTO) Scopo
  47. 47. Data Transfer Object (DTO) Soluzione
  48. 48. Data Transfer Object (DTO) Scopo • In una tradizionale architettura EJB, un DTO ha un duplice scopo: – porre riparo al problema derivante dal fatto che gli entity beans pre- ejb 3.0 (in J2EE) non sono serializzabili; – definire implicitamente una fase di assemblaggio dove tutti i dati che devono essere usati da una view sono prelevati e marshallizzati nei DTO prima di restituire il controllo al presentation layer.
  49. 49. Data Transfer Object (DTO) Problema • Si vogliono trasferire molti dati lungo più layers di un’applicazione. In particolare, si vuole che il client possa accedere ai componenti di diversi layer per recuperare o aggiornare dati. • 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 dati sia per il salvataggio degli stessi.
  50. 50. Data Transfer Object (DTO) Soluzione • Utilizzare un Data Transfer Object per incapsulare i dati di business. Una singola chiamata a un metodo è usata per inviare e recuperare il Transfer Object. • Quando il cliente richiede dei dati di business, il DTO viene istanziato e popolato con i rispettivi valori e poi passato al client. • Esso viaggia lungo tutti gli strati dell’applicazione.
  51. 51. Data Transfer Object (DTO) Presentation Business Data Access DTO DTO
  52. 52. Data Transfer Object (DTO) Soluzione
  53. 53. Data Transfer Object (DTO) Caratteristiche • Il DTO è un oggetto dotato di caratteristiche particolari: – è serializzabile, – contiene solo proprietà e – non ha all’interno alcuna logica di business. • Come dice lo stesso nome del pattern è quindi un oggetto che serve per trasferire dei dati. • In uno scenario di invocazione remota, fare numerose chiamate al server per ottenere dei dati causa un network overhead non indifferente; per questo motivo bisogna cercare di minimizzare queste chiamate al server e il DTO ci aiuta.
  54. 54. Data Transfer Object (DTO) Struttura
  55. 55. Data Transfer Object (DTO) Esempio: interazione senza utilizzo DTO
  56. 56. Data Transfer Object (DTO) Esempio: interazione con server mediante DTO
  57. 57. Data Transfer Object (DTO) Esempio • Possiamo infatti inserire nel DTO tutte le informazioni che vogliamo farci restituire dal server in modo tale da fare una sola chiamata. • Stesso ragionamento se vogliamo salvare delle informazioni, infatti fare più chiamate per il salvataggio è oneroso, invece farne una sola passando i dati da salvare nel DTO è più efficiente.
  58. 58. Data Transfer Object (DTO) Implementazione • Vi sono due approcci base per la costruzione del DTO: – Creare un DTO per ogni entità nel modello dei dati. Questo approccio consente una completa trasposizione del modello e quindi una completa interazione con le entità in ottica di recupero informazioni o salvataggio. – Creare un DTO thin, inserendo solo le informazioni di cui abbiamo bisogno. Questo ha pro e contro, infatti un vantaggio è sicuramente l’aumento delle prestazioni visto che i dati da serializzare e deserializzare saranno di meno, tuttavia lo svantaggio è che nel momento in cui vogliamo un campo in più dovremmo modificare lato codice il DTO con tutte le conseguenze che ne derivano.
  59. 59. Data Transfer Object (DTO) Implementazione • Considerando che un progetto è soggetto a continui cambiamenti nei requisiti, probabilmente se non ci sono problemi di prestazioni, la prima scelta è quella più opportuna. • Ecco un esempio, in Java, di un DTO.
  60. 60. Data Transfer Object (DTO) Implementazione • Considerando che un progetto è soggetto a continui cambiamenti nei requisiti, probabilmente se non ci sono problemi di prestazioni, la prima scelta è quella più opportuna. • Ecco un esempio, in Java, di un DTO.
  61. 61. 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; } }
  62. 62. Data Transfer Object (DTO) Implementazione • Come potete notare, dal punto di vista prettamente di codice Java, un DTO è un POJO che implementa l’interfaccia Serializable.
  63. 63. 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()); } }
  64. 64. Data Transfer Object (DTO) Sequence diagram
  65. 65. Data Transfer Object (DTO)
  66. 66. Data Transfer Object (DTO) Conseguenze • Le conseguenze che derivano dall’utilizzo dei Data Transfer Objects sono: – riduzione del traffico di rete – semplificazione delle interfacce remote – riduzione del codice duplicato – trasferimento di una maggior quantità di dati in meno chiamate remote
  67. 67. BUSINESS OBJECT PoEAA - pag. 117
  68. 68. BUSINESS OBJECT
  69. 69. Business Object Problema • Si ha un’applicazione con un modello concettuale complesso, dotato di una logica di business sofisticata, con regole di validazione complesse e oggetti complessi correlati. • Si vuole separare lo stato di business e il relativo comportamento dal resto dell’applicazione, incrementandone così coesione e riusabilità. • Inoltre, si vuole evitare la duplicazione del codice.
  70. 70. 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
  71. 71. 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
  72. 72. 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
  73. 73. Business Object Soluzione • Si utilizza un insieme di Business Objects per separare i dati 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 dati di business, così da separare la logica di business dai dati di business.
  74. 74. Business Object Soluzione • Viene creato un layer di Business Object che rappresentano il domain model • Permette di separare il modello di dati dalla sua persistenza • Aumenta la riusabilità del codice
  75. 75. Business Object: strategie Implementazioni tipiche: • BO come POJO, con un meccanismo di persistenza tipo: • Data Access Object  Integration Tier Pattern • JDO • Tool di persistenza - ORM (Hibernate, ...) • BO come Enterprise Java Bean (EJB) • CMP • BMP
  76. 76. Business Object Conseguenze • Tra le conseguenze che derivano dall’utilizzo di tale pattern abbiamo: – evita la duplicazione del codice e favorisce la manutenibilità dello stesso – separa la logica di persistenza dalla logica di business – promuove un’architettura di tipo service-oriented – aggiunge un ulteriore strato di indirezione
  77. 77. APPLICATION SERVICE PoEAA - pag. 117
  78. 78. Application Service Spesso è difficile esprimere tutta la logica applicativa in termini di business object • use-case complessi e/o articolati • aumenta l’accoppiamento degli oggetti del domain model • difficile ed improprio gestire nei BO problematiche di transazionalità o sicurezza
  79. 79. Application 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
  80. 80. Application Service • Centralizza la logica riusabile, evitando duplicazioni di codice • Può gestire problematiche di transazionalità e sicurezza • Introduce un nuovo livello (Service Layer) all’interno del Business Tier
  81. 81. Application 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 ServicePresentation
  82. 82. Application Service Command Strategy Client ApplicationService ServiceFacade «Pojo» Helper ApplicationController - invokes CommandFactory Command + execute ( ) - uses - invokes - creates - invokes
  83. 83. SERVICE LOCATOR PoEAA - pag. 117
  84. 84. Service Locator L’accesso ai componenti di business può essere complesso Client Ejb Anche utilizzando JNDI il codice necessario ad effettuare queste operazioni è poco leggibile e duplicato POJO Jms Service
  85. 85. Service Locator Client Ejb DbServiceLocator Nasconde la complessità di lookup e creazione Fornisce una modalità di accesso uniforme Memorizza in cache i dati Service
  86. 86. Service Locator Client «Singleton» ServiceLocator- uses 1 1..* TargetService - _looksup - accesses Cache - mantains - caches InitialContext- creates/uses RegistryService - refers - resolves Una implementazione tipica
  87. 87. BUSINESS DELEGATE PoEAA - pag. 117
  88. 88. Business Delegate Quando accedo ad un client ad un servizio remoto (Ejb, Jms) il codice di connessione ed invocazione è complesso e mescolato al codice applicativo Client Session Ejb
  89. 89. Business Delegate Un Business Delegate incapsula l’accesso ad un servizio remoto, nascondendo i dettagli dell’implementazione di lookup e del meccanismo di accesso. – Riduce l’accoppiamento tra componenti (il client non conosce la tecnologia del servizio remoto) – Traduce le eccezioni che arrivano dal servizio remoto – Può implementare meccanismi di recovery e caching
  90. 90. Business Delegate Client «Pojo» BusinessDelegate «Singleton» ServiceLocator - uses - accesses «interface» BusinessService EjbService JmsService - accesses looksup
  91. 91. Un’architettura per il BT Dati BO BO BO BO Client Client Servizio Servizio Delegate Delegate Service Locator
  92. 92. Passato, Presente e Futuro ... dei pattern ... • Studio delle applicazioni esistenti • Best practice per la progettazione • Model Driven Architecture (MDA) e pattern
  93. 93. Referenze http://www.corej2eepatterns.com Alur, Crupi, Malks, Core J2ee Patterns – Best Practices and Design Strategies, 2nd edition, Prentice Hall, 2003

×