Recommended approaches to AOP with Windsor
time to read 2 min | 268 words

In my Policy Injection With Windsor (in 40 minutes), I mentioned that things like the Policy Injection Block are not a really good approach to doing AOP using Windsor. What I meant that I wouldn't build something like the Policy Application Block, simply because it doesn't really gives me anything special.

The use cases for simple interception AOP are quite limited. Mostly logging, performance monitor, and that about it. But its very nature, AOP is an infrastructure entity, and will generally not take part of any meaningful business logic.

 Can someone think about an interesting scenario involving AOP and business logic that wouldn't invoke a WTF?!

If you want to do some of the really interesting stuff with AOP, you generally want to know more than just the method you intercepted, you want to have configuration, access to the object you are intercepting, maybe collaborate with additional objects. Using an approach like the Policy Injection Block, it is fairly hard to do. You generally try to do a lot more with XML than you should.

When I am using AOP, I am mainly build scenario driven facility + interceptor + inspector / contributer. It is not a lot of code (and certainly not repeated one) and it gives me a lot of flexibility without having to put extensability hooks all over the place. This also mean that my model for AOP is more coherent than it would be otherwise.

Tweet Share Share 0 comments
Tags: