Aspect Orientation is a way to structure your application so that some concerns (usually cross cutting, mostly infrastructure) are handled transparently by the framework you are running on. The classic examples are logging & auditing, but I am using it for transactions, thread safety, mocking, resource cleanup, validation and more. It is a good tool to have, and it can make some things very easy to handle.*

I am writing this post because I have dealt with AoP and derivatives quite often in the recent past, and I had some minor part in building some tools which are key for  Aspect Orientation in .Net (Dynamic Proxy). The problem with AOP on the CLR is that it requires extra steps on the part of the developer to get to it.

The CLR doesn't support AOP, and considering the need ** for that, it is fairly surprising that it isn't there. Furthermore, it seems like there is no intention to add that to the CLR. This is especially problematic in light of the non-virtual by default that we have in most CLR languages.

Since the platform doesn't give us AOP out of the box, we are left with hacks & half measures. Dynamic Proxy, the Policy Injection Block, partial methods and the like are all things that have been built because AOP is the correct answer to a certain class of problems. Considering that two of those are coming from Microsoft, I would like to see this being turned into giving us true AOP capabilities baked into the platforms.

There are 7 overall approaches to AOP in .Net, all of them has some serious limitations, and the ones that do give me what I would consider true AOP require that I would use the profiling / debugging API (special launcher, COM API, complex) or do IL re-weaving, which is simply hard & unproductive.  I am doing some work on Dynamic Proxy, and I can tell you up front that trying to workaround some of the issues there is very hard. That should be a service offered by the platform, not something that I would need to supply.

Nitpicker corner:

* Nevertheless, Aspect Orientation is not a Silver Bullet.

** You might not feel the need in your application, but I do. Rhino Mocks is entirely built on the idea of method interception, which is a core part of what AOP needs.