Design Patterns - enterprise patterns (part I)
Download as PPTX, PDF6 likes3,256 views
Il documento esamina vari pattern architetturali utilizzati nello sviluppo di applicazioni aziendali, con particolare attenzione ai pattern J2EE. Vengono descritti pattern come il Front Controller e il Data Transfer Object (DTO), illustrando i loro benefici come la centralizzazione della logica di controllo e la riduzione del traffico di rete. Inoltre, si discute la separazione della logica di business e delle responsabilità di presentazione, migliorando la manutenibilità e la riusabilità del codice.
Design Patterns - enterprise patterns (part I)
- 2. fabio.armani
- 3. Overview • Analysis patterns • Architectural patterns • Design patterns • Enterprise patterns • GRASP patterns • Implementation patterns • J2EE Core patterns • SCM patterns
- 5. Enterprise Patterns • Patterns of Enterprise Application Architecture • Core J2EE Patterns • Integration Patterns
- 6. Enterprise Patterns > books
- 8. Core J2EE Patterns • Presentation Tier • Business Tier • Integration Tier
- 9. Core J2EE Patterns • Presentation Tier – Application Controller – Composite View – Context Object – Dispatcher View – Front Controller – Intercepting Filter – Service To Worker – View Helper
- 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. 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
- 12. Presentation Tier Pattern • Front Controller • View Helper • Composite View • Dispatcher View
- 13. FRONT CONTROLLER PoEAA - pag. 117
- 14. FRONT CONTROLLER
- 15. FRONT CONTROLLER
- 16. Front Controller Descrizione • Consente di gestire il mapping logico delle risorse
- 17. 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.
- 18. 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.
- 19. 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
- 21. Front Controller
- 22. Front Controller
- 23. Front Controller
- 24. 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.
- 25. 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
- 26. Front Controller
- 27. Front Controller
- 28. VIEW HELPER PoEAA - pag. 117
- 29. VIEW HELPER
- 30. 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.
- 31. View Helper Problema • Si vuole separare la vista dalla sua logica di elaborazione.
- 32. 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.
- 33. 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).
- 34. View Helper Avoid: • XSLT and Xpath Vulnerabilities • Unencoded User Supplied Data Use to Implement: • Output Encoding in Custom Tag Helper Class diagram
- 36. View Helper
- 37. 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
- 38. 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
- 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
- 40. 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
- 41. DATA TRANSFER OBJECT PoEAA - pag. 117
- 42. DATA TRANSFER
- 43. 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).
- 44. 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.
- 45. Data Transfer Object (DTO) Presentation Business Data Access
- 46. 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).
- 47. Data Transfer Object (DTO) Scopo
- 48. Data Transfer Object (DTO) Soluzione
- 49. 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.
- 50. 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.
- 51. 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.
- 52. Data Transfer Object (DTO) Presentation Business Data Access DTO DTO
- 53. Data Transfer Object (DTO) Soluzione
- 54. 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.
- 55. Data Transfer Object (DTO) Struttura
- 56. Data Transfer Object (DTO) Esempio: interazione senza utilizzo DTO
- 57. Data Transfer Object (DTO) Esempio: interazione con server mediante DTO
- 58. 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.
- 59. 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.
- 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. 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.
- 62. 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; } }
- 63. 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.
- 65. 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()); } }
- 66. Data Transfer Object (DTO) Sequence diagram
- 67. Data Transfer Object (DTO)
- 68. 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
- 69. BUSINESS OBJECT PoEAA - pag. 117
- 70. BUSINESS OBJECT
- 71. 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.
- 72. 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
- 73. 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
- 74. 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
- 75. 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.
- 76. 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
- 77. 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
- 78. 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
- 79. APPLICATION SERVICE PoEAA - pag. 117
- 80. 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
- 81. 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
- 82. 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
- 83. 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 Service Presentation
- 84. Application Service Command Strategy Client ApplicationService ServiceFacade «Pojo» Helper ApplicationController - invokes CommandFactory Command + execute ( ) - uses - invokes - creates - invokes
- 85. SERVICE LOCATOR PoEAA - pag. 117
- 86. 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
- 87. 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
- 88. Service Locator Client «Singleton» ServiceLocator - uses 1 1..* TargetService - _looksup - accesses Cache - mantains - caches InitialContext - creates/uses RegistryService - refers - resolves Una implementazione tipica
- 89. BUSINESS DELEGATE PoEAA - pag. 117
- 90. 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
- 91. 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
- 92. Business Delegate Client «Pojo» BusinessDelegate «Singleton» ServiceLocator - uses - accesses «interface» BusinessService EjbService JmsService - accesses looksup
- 93. Un’architettura per il BT Dati BO BO BO BO Client Client Servizio Servizio Delegate Delegate Service Locator
- 94. Passato, Presente e Futuro ... dei pattern ... • Studio delle applicazioni esistenti • Best practice per la progettazione • Model Driven Architecture (MDA) e pattern
- 95. Referenze http://www.corej2eepatterns.com Alur, Crupi, Malks, Core J2ee Patterns – Best Practices and Design Strategies, 2nd edition, Prentice Hall, 2003