net uy meetup 4 - aop & postsharp by bruno bologna & fabian fernandez

AOP&

@bolognabruno@fabifernandez23

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

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

¿Que es el mal diseño?

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

Arreglar algo mal diseñado...

Ejemplo de código - MeetupApp

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.

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

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.

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.

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

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

Responsabilidades cross-cutting

• Logging• Auditoria• Transacciones• Locking & thread dispatching• Caching• Exception handling

Principios que cumple AOP

• DRY (Don't Repeat Yourself)• Principios SOLID• Single Responsibility• OPEN/CLOSE

¿Como funciona AOP?

Identificamos responsabilidades Cross-Cutting

Creamos un aspecto para dicha responsabilidad

Aplicamos el aspecto a nuestras clases

Tipos AOP

Interceptors• Usa el patrón DynamicProxy• Se resuelve en tiempo de ejecuciónIL Code Weaving• Inyecta código en tiempo de compilación• No usan DynamicProxy

Interceptors

IL Code Weaving

Comparación de frameworks

Features de cada framework

De que forma podemos aplicar aspectos

Otros puntos importantes

http://postsharp.net

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

CompileTime

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

OnMethodBoundaryAspect

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

OnExceptionAspect

• Aspecto a nivel de método– OnException– GetExceptionType

LocationInterceptionAspect

• Aspecto a nivel de propiedades y campos• Permite interceptar Get y Set– OnGetValue– OnSetValue

• Operaciones útiles– ProceedGetValue()– ProceedSetValue()– GetCurrentValue()– SetNewValue()

EventInterceptionAspect

• Aspecto a nivel de eventos– OnAddHandler (+=)– OnRemoveHandler(-=)– OnInvokeHandler

• Operaciones útiles– ProceedAddHandler()– ProceedRemoveHandler()

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!

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

Aplicando P# a codigo existente

• Arrancar con lo más papa!– Logging & Tracing– Monitoreo de performance– Caching– Exception handling

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

GRACIAS!

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/