1. AOP
Strutturare il codice per aop

2. Chi sono??
• Ricci Gian Maria
• Alkampfer@nablasoft.com
• Twitter: @alkampfer
• Blog: http://www.codewrecks.com

3. Cosa è AOP
• I principi OO non permettono di modellare
comportamenti “trasversali” agli oggetti
• Si dice “trasversale” un comportamento
valido per più oggetti
• AOP permette di applicare un
comportamento su un oggetto
• Per comportamento si intende
l’esecuzione di codice quando viene
chiamato un metodo o una proprietà di un
oggetto.

4. Weaving
• Weaving is the textile art in which two
distinct sets of yarns or threads, called the
warp and the filling or weft (older woof),
are interlaced with each other to form a
fabric or cloth
• Nella programmazione il concetto di
Weaving è appunto correlato all’intrecciare
il comportamento degli oggetti base con
gli aspetti
• Esistono molti modi di effettuare Weaving

5. Compile Time Weaving
• Per compile time weaving si intende la
possibilità di applicare gli aspetti a livello
di codice sorgente
• Modificaer i sorgenti prima della
compilazione
• Supporto da parte del compilatore
• Effettuare una post decompliazione e
ricompilazione (post sharp)

6. Run time Weaving
• Modificare il comportamento di un
oggetto durante l’esecuzione
• Profiler API
• Decorator Pattern
• Dynamic generation of proxy (Castle,
Spring, Aspect#)
• ContextBoundObjet (Enterprise library
policy Injection Application Block).

7. RUN TIME WEAVING
CON DECORATOR
PATTERN

8. Prerequisiti
• Il Run-Time weaving è possibile solo in
situazioni di basso accoppiamento
• Se il chiamante istanzia direttamente un
oggetto, quest’ultimo non può supportare
AOP
• AOP è quindi un concetto che si sposa
perfettamente con IoC / DI
• Il chiamante utilizza interfacce e non
necessita di sapere l’istanza concreta che
viene usata.

9. Decorator pattern
• Il chiamante vuole interagire con un
ISendMessage
• Esiste un’implementazione concreta
chiamata SmsMessageSender
• Si crea un wrapper con l’aspetto
desiderato
• Si registra nel contenitore IoC o il
componente SmsMessageSender
• Se necessario si effettua il wrapping con il
decorator

10. Decorator pattern
La chiamata viene intercettata e viene
semplicemente propagata al
RealSubject

11. DEMO

12. Decorator pattern
• Implementazione semplice ma poco
riutilizzabile.

13. RUN TIME WEAVING
CON CASTLE
WINDSOR

14. Interceptors
• Il Run Time weaving si basta spesso sulla
generazione dinamica di proxy
• Per ogni interfaccia su cui si vuole fare
AOP viene creato dinamicamente un proxy
con il prinicpio del decorator
• In questo proxy vengono inserite delle
chiamate agli eventuali intercettori che
implementano una data interfaccia
• Il programmatore deve solamente
implementare l’interfaccia richiesta, la
libreria fa tutto il resto

15. Interceptors
Interceptor1 Interceptor2 Interceptor3 interceptor4
• Un intercettore è in grado di rispondere ad
un evento di chiamata di un metodo
• Ogni intercettore può o meno far
proseguire la chiamata
• Un intercettore è in grado di cambiare i
valori di ritorno e gestire le eccezioni

16. Interceptors
• Nel flusso normale ogni intercettore
esegue il suo codice e fa proseguire la
chiamata
• Alcuni componenti possono alterare il
flusso
• Il componente tipico che ha questo
comportamento è ad esempio l’aspetto di
cache.
• Se il componente individua che la
chiamata può essere cachata allora non la
propaga

17. DEMO

18. AOP SU SERVIZI WCF
CON CASTLE
WINDSOR

19. AOP su servizi WCF
• L’ambiente WCF è il classico in cui molte
funzionalità sono trasversali
• La soluzione più elegante è soddisfare
tutte le funzionalità comuni a tutti i servizi
tramite AOP
• Per fare questo è necessario innanzitutto
far si che le classi usate per servire una
richiesta WCF vengano instanziate da
Castle.
• La WCF castle facility si occupa di risolvere
la classe che gestisce il servizio tramite un
contenitore windsor.

20. AOP su servizi WCF
• Una volta che il servizio viene risolto con
Castle è possibile aggiungere gli aspetti
necessari.
• I servizi rappresentano uno dei punti più
semplici ed intuitivi dove inserire aspetti
tramite AOP
• Gli aspetti generici per i servizi solitamente
sono infatti applicati a tutti i metodi e non
è nemmeno necessario effettuare logica di
selezione.

21. DEMO

22. Altri aspetti tipici
• Security: un aspetto che ad ogni chiamata
controlla su un db o su file i permessi
richiesti per ogni metodo ed esegue una
security assertion
• Cache: su alcuni metodi usare un cache
provider per memorizzare il risultato di
una chiamata ad un servizio wcf
• Test su dev: un aspetto in produzione che
duplica ogni chiamata su un servizio dev
per verificarne la compabilità retroattiva
(penalizza un poco le performance in
produzione)