Tag Archives: aop

don’t be scared, it’s just me, aop…

aop (aspect-oriented programming)  is a concept i’ve always liked/hated in equal parts.  i think any typical object-oriented programmer likely rails against the concept of having aspects injected into their code at compile/run-time based on a couple of class decorators.  i think i’ve come to the point though where i get the benefit.  the whole cross-cutting concerns thing kind of hits home, so i’ve been investigating it.

a long time ago, a friend and i were discussing aop, and postsharp came up.  If you don’t know what it is, or what it does, let me begin by saying it is crazy.  hats off to the guys at sharpcrafters for devising something so wickedly magical.  the basic idea is that you inherit from certain attributes that they define, and then decorate classes with those new aspects.  thats all well and good, normal aspect oriented stuff so far.  it gets crazy at compile-time.  postsharp hooks into the compiler and actually alters the IL that is run on the CLR, basically adding code to your code, without you having to do anything but add an attribute.  want every method on your class to be wrapped in a try/catch where the catch logs the exception and then throws it back out?  add a attribute, build, and voila, you now have logging around every method.  not only do you have logging, but unlike other dynamic proxy based solutions, it’s testable.  i’m not sure that i’d ever want/need to test this kind of boiler plate logging, but lets assume a more complex scenario like wrapping methods with a TransactionScope, or decorating certain methods for audit logging.  these things both reflect real business behavior, and should be testable, but using an IoC container + dynamic proxy will not allow for unit testing that these aspects are appropriately applied.

postsharp’s IL weaving allows for testable AOP, and i think i can stand behind that.  For now.

Tagged ,