Fredrik Normén recently posted about how crosscutting concerns are implemented with boring and often duplicated code, which can be handled by using aspect oriented programming (AOP). I have used AOP with great success in previous projects to handle scenarios like logging, transactions and change tracking.

The problem with AOP is that it is not well supported or integrated into the CLR or the .NET framework and toolset. Sure there are great AOP frameworks that solve the problem via dynamic proxies, but such solutions have some big restrictions, for example they only work with virtual functions and you need to instantiate the object via a proxy creator. PostSharp handled AOP differently, it is a framework and a .NET post compiler that injects your crosscutting concerns at compile time. The problem I have found with PostSharp is that the post compile step is kind of slow, which is an issue if you do TDD (because you are constantly recompiling). Beside the compile time issue PostSharp is great tool and framework with great flexibility and power.

I was kind of disappointed that Microsoft didn't present any plan to make AOP scenarios easier and more natural on the .NET platform at this years PDC. I am not sure how, but I just feel that the AOP experience on .NET could be vastly improved :)


Roger Alsing said...

This is my view on this matter:

I can not see why on earth people would want AOP to break the most fundamental rules.

Eg, if you are only allowed to change the behaviour of virtual methods via OOP.

Then why should you be allowed to do so using AOP?

AOP needs to conform to the OOP rules or we will end up with all sorts of problems.

Just my 2 cents atleast..

Torkel Ödegaard said...

Sure AOP might break some OOP rules, but you have to be a little pragmatic, if it can save hundreds of lines of code and make your code cleaner then that violation might be OK. At least in my book :)