Design Patterns - enterprise patterns (part I)

ENTERPRISE PATTERNS
fabio.armani

Overview
• Analysis patterns
• Architectural patterns
• Design patterns
• Enterprise patterns
• GRASP patterns
• Implementation patterns
• J2EE Core patterns
• SCM patterns

Enterprise Patterns
• Patterns of Enterprise Application Architecture
• Core J2EE Patterns
• Integration Patterns

Core J2EE Patterns
• Presentation Tier
• Business Tier
• Integration Tier

Core J2EE Patterns
• Presentation Tier
– Application Controller
– Composite View
– Context Object
– Dispatcher View
– Front Controller
– Intercepting Filter
– Service To Worker
– View Helper

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

Presentation Tier Pattern
• Front Controller
• View Helper
• Composite View
• Dispatcher View

FRONT CONTROLLER
PoEAA - pag. 117

Front Controller
Descrizione
• Consente di gestire il mapping logico delle risorse

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.

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.

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

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.

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

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.

View Helper
Problema
• Si vuole separare la vista dalla sua logica di elaborazione.

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.

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).

View Helper
Avoid:
• XSLT and Xpath
Vulnerabilities
• Unencoded User Supplied
Data
Use to Implement:
• Output Encoding in
Custom Tag Helper
Class diagram

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

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

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

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

DATA TRANSFER OBJECT
PoEAA - pag. 117

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).

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.

Presentation
Business
Data Access

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).

Scopo

Soluzione

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.

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.

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.

Presentation
Business
Data Access
DTO
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.

Struttura

Esempio: interazione senza utilizzo DTO

Esempio: interazione con server mediante 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.

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.

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.

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;
}
}

Implementazione
• Come potete notare, dal punto di vista prettamente di codice
Java, un DTO è un POJO che implementa l’interfaccia
Serializable.

// 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()); } }

Sequence diagram

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

BUSINESS OBJECT
PoEAA - pag. 117

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.

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
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
BO
BO
Utilizzare Business Object che incapsulano dati e logica e che
delegano ad altri componenti la loro persistenza
DBMS

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.

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

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

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

APPLICATION SERVICE
PoEAA - pag. 117

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

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

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

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

Application 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 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

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 applicativo
Client
Session
Ejb

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

Business Delegate
Client
«Pojo»
BusinessDelegate
«Singleton»
ServiceLocator
- uses
- accesses
«interface»
BusinessService
EjbService JmsService
- accesses
looksup

Un’architettura per il BT
Dati
BO
BO
BO
BO
Client
Client
Servizio
Servizio
Delegate
Delegate
Service
Locator

Passato, Presente e Futuro
... dei pattern ...
• Studio delle applicazioni esistenti
• Best practice per la progettazione
• Model Driven Architecture (MDA) e pattern

Referenze
http://www.corej2eepatterns.com
Alur, Crupi, Malks, Core J2ee Patterns –
Best Practices and Design Strategies,
2nd edition, Prentice Hall, 2003

Design Patterns - enterprise patterns (part I)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (6)

Ähnlich wie Design Patterns - enterprise patterns (part I)

Ähnlich wie Design Patterns - enterprise patterns (part I) (20)

Mehr von Fabio Armani

Mehr von Fabio Armani (19)

Design Patterns - enterprise patterns (part I)