7 Approaches for AOP in .Net
Here are all the ways that I can think of to add AOP to your application. This mostly focus on the interception side of things, because once you have that, everything else it just details.
Approach | Advantages | Disadvantages |
Remoting Proxies | Easy to implement, because of the .Net framework support | Somewhat heavy weight Can only be used on interfaces or MarshalByRefObjects |
Deriving from ContextBoundObject | Easiest to implement Native support for call interception |
Very costly in terms of performance |
Compile-time subclassing ( Rhino Proxy ) |
Easiest to understand |
Interfaces or virtual methods only |
Runtime subclassing ( Castle Dynamic Proxy ) |
Easiest to understand Very flexible |
Complex implementation (but already exists) Interfaces or virtual methods only |
Hooking into the profiler API ( Type Mock ) |
Extremely powerful | Performance? Complex implementation (COM API, require separate runner, etc) |
Compile time IL-weaving ( Post Sharp / Cecil ) |
Very powerful Good performance |
Very hard to implement |
Runtime IL-weaving ( Post Sharp / Cecil ) |
Very powerful Good performance |
Very hard to implement |
Comments
Looking at the code for Rhinomocks, I was pretty sure you were using Dyanmic Proxy to create the mocks (at runtime). You're not?
yes
Hmm, almost a year ago I was looking into AOP. This was just after reading a book about AOP in Java. I found out some people also find Declarative Programming using Attributes a way of Aspect Oriented Programming. I'm not sure about this. Yes we are centralizing our concerns, but we are coupling them tightly with our objects.
You can have a look at AspectDNG if you want to have a look at a static weaver that is already implemented.
http://aspectdng.tigris.org
I wrote an interception infrastructure using remoting proxies/ContextBoundObject a few years ago, and here's why I think it doesn't fly:
However, AOP is very incomplete if you can only intercept method calls on object boundaries.
Using the profiler API is probably the most fragile and unportable here. So this gives us a choice of either subclassing or weaving. I suspect the biggest problem with weaving is binary compatibility. I wonder how this is dealt with when weaving strong-named assemblies.
The major problems of sublcassing are:
http://blogs.msdn.com/ericlippert/archive/2007/06/14/calling-static-methods-on-type-variables-is-illegal-part-one.aspx (second comment)
You could add that weaving gives you more power to hook right into the body of an existing method, but depending on your point of view, that is not necessarily an advantage. Subclassing constrains you to the interfaces that the author of a class defined, so your aspects should not break if that class changes (or anything derived from that class could break, so at least there is no new category of breaking changes that the author might not be aware of). I think even with AOP you should treat other people's methods as black boxes, unless you use AOP for patching.
I would like to see this expanded to see what issues each one address.
Here is one more approach to AOP: http://dotnet.agilekiwi.com/blog/2007/07/claytons-interception.html
Here is one more approach to AOP: http://dotnet.agilekiwi.com/blog/2007/07/claytons-interception.html
Comment preview