1. AOP
&
@bolognabruno
@fabifernandez23

2. Agenda
•
•
•
•
•
•
•
•
¿Que es el mal diseño?
¿Que es AOP?
¿Como funciona AOP?
Tipos AOP
Postsharp
Vida de un aspecto
Out of the Box Aspects
Consideraciones con Postsharp

3. ¿Que es el mal diseño?
• Recordemos momentos que nos vimos
enfrentados a código mal diseñado.
• Analicemos que características hacen que el
código no sea bueno.

4. ¿Que es el mal diseño?

5. Dificultades de un mal diseño
• Muy difícil modificar código sin introducir
nuevos bugs.
• Por más que se corrijan bugs, el mal diseño se
mantiene y cada vez tiende a ser peor

6. Arreglar algo mal diseñado...

7. Ejemplo de código - MeetupApp

8. Un pequeño análisis
• Por cada bloque de código que queremos
encerrar en try/catch estamos utilizando al
menos 8 líneas más de código.

9. A la hora de crecer...
• 10 métodos que encierran código en bloques
try/catch representarían al menos 80 líneas de
código repetido

10. Esto no es nuevo...
• Un estudio publicado por IEEE TRANSACTIONS ON
SOFTWARE ENGINEERING demostró que la cantidad
de defectos en una funcionalidad están relacionadas
en dos factores:
1. La cantidad de lineas de código que componen
dicha funcionalidad .
2. La repetición de dicha funcionalidad a traves de
varios artefactos de código.

11. Ademas...
• También demostró que las responsabilidades
"cross-cutting" repetidas en la aplicación
suelen tener más defectos que las clásicas
funcionalidades de negocio.

12. ¿Que es AOP?
• AOP es una técnica de desarrollo de software
que apunta a incrementar la modularidad
permitiendo separación de responsabilidades
"cross-cutting".
• Esta técnica complementa y no remplaza el
paradigma actual de programación orientada
a objetos.

13. ¿Que es AOP?
• Con AOP podemos definir funcionalidad
"cross-cutting" en un único lugar y aplicarla
declarativamente donde sea necesario sin
modificar la clase donde aplica esta
funcionalidad.

14. Responsabilidades cross-cutting
•
•
•
•
•
•
Logging
Auditoria
Transacciones
Locking & thread dispatching
Caching
Exception handling

15. Principios que cumple AOP
• DRY (Don't Repeat Yourself)
• Principios SOLID
•
Single Responsibility
•
OPEN/CLOSE

16. ¿Como funciona AOP?

17. Identificamos responsabilidades CrossCutting

18. Creamos un aspecto para dicha
responsabilidad

19. Aplicamos el aspecto a nuestras clases

20. Tipos AOP
Interceptors
• Usa el patrón DynamicProxy
• Se resuelve en tiempo de ejecución
IL Code Weaving
• Inyecta código en tiempo de compilación
• No usan DynamicProxy

21. Interceptors

22. IL Code Weaving

23. Comparación de frameworks

24. Features de cada framework

25. De que forma podemos aplicar
aspectos

26. Otros puntos importantes

28. http://postsharp.net

29. Vida de un Aspecto
• Compila tu assembly
• Entra PostSharp a jugar:
– Se instancia el aspecto para el target code
– CompileTimeValidation
– CompileTimeInitialization
– Serialización por target code
• Managed resource
– Binary stream (default)
– XML
– MSIL
Compile
Time

30. Vida de un Aspecto
• Run Time
– Deserialización
– RunTimeInitialize (1 vez – la app está lista)
– RunTimeInstanceInitialize (cada vez que el target
code se inicializa)
– Ejecución del advice
• Ctor() no se ejecuta en Run Time

31. OnMethodBoundaryAspect
• Aspecto a nivel de método
– OnEntry
– OnExit
– OnException
– OnSuccess

32. OnExceptionAspect
• Aspecto a nivel de método
– OnException
– GetExceptionType

33. LocationInterceptionAspect
• Aspecto a nivel de propiedades y campos
• Permite interceptar Get y Set
– OnGetValue
– OnSetValue
• Operaciones útiles
– ProceedGetValue()
– ProceedSetValue()
– GetCurrentValue()
– SetNewValue()

34. EventInterceptionAspect
• Aspecto a nivel de eventos
– OnAddHandler (+=)
– OnRemoveHandler(-=)
– OnInvokeHandler
• Operaciones útiles
– ProceedAddHandler()
– ProceedRemoveHandler()

36. Aplicando P# a codigo existente
• Buscar código que sea claramente un patrón
decorador
• Buscar aspectos que no interactuen con el target
code
• Elegir la mejor forma de agregarlos: multicast o
atributos individuales
– Individual = más control
– Multicast = más fácil pero el código debe estar bien
organizado para tener control
• TEST, TEST, TEST!

37. Aplicando P# a codigo existente
• Verificar que no hay efectos secundarios
– Considerar los aspectos como islas de alta
encapsulación
– Sólo lectura de la meta data del target code
– No intentar alterar el flujo de ejecución

38. Aplicando P# a codigo existente
• Arrancar con lo más papa!
– Logging & Tracing
– Monitoreo de performance
– Caching
– Exception handling

39. Deployment
• PostSharp.dll y listo!
• Si usas ILMarge
– Merge de varios assemblies en uno
– Se complica un poco!
• Si firmas los assemblies, usar delay signing
• Obfuscas tu código?
– Sólo soporta dotFuscator

41. GRACIAS!

42. Referencias
•
•
•
•
•
•
•
Dynamic Decorator Pattern http://goo.gl/DkIe1t
Dynamic Proxies http://goo.gl/ql6Zly
Documentación PostSharp http://goo.gl/mH3l6J
White-paper AOP http://goo.gl/Mtzy0u
Artículo Técnico PostSharp http://goo.gl/NxD380
Presentaciones AOP http://goo.gl/v6OYmm
Aspect Oriented Programming in .NET
http://goo.gl/HNKlaA
• PostSharp Fundamentals http://goo.gl/LPIawa
• ILSpy http://ilspy.net/