Thoughts on Software

Brief Introduction to Aspect Oriented Programming

with 3 comments

One problem I have frequently encountered when developing enterprise systems is that of applying functionality that is required by many objects within a system but which is not core to the concerns of those objects, such as logging or transactional behaviour.

Aspect Oriented Programming, or AOP, refers to this type of functional requirements as cross-cutting concerns and is designed specifically to address this issue: if such requirements are met by coding the cross-cutting concern into objects throughout the system, we can easily end up with a messy, hard-to-maintain implementation split across many objects.

The classic example of a cross-cutting concern is logging: logging is essential to any real, live system and needs to be implemented throughout that system, but is not really a concern of the objects within that system: the system may need to log the inner workings of a sales-tax calculation object but logging is hardly a concern of the sales-tax calculation object itself.

Another example of where AOP could be useful is transactions. If we try and implement this in code within objects we risk ending up with objects that are aware that they are acting within a transaction which is, to my mind, not a desirable design feature. AOP allows us to create and co-ordinate transactions externally to the objects taking part in the transaction, which can give a much more stable, maintenance-friendly design.

AOP allows us to specify these system-wide (cross-cutting) requirements separately to our main business logic and then weave the two together, either at run-time or compile-time. AOP works by intercepting calls to methods on objects. The interception points are known as pointcuts and the intercepted method is the advised method, with the code being advised on the intercepted method being known as the advice.

I am most familiar with AOP via Spring.Net’s AOP Framework which allows you to specify and apply pointcuts and advices both via configuration files and programmatically and performs the weaving at run-time. Spring.Net AOP has four types of advice: before, after, around and throws which are invoked on interception of an advised method before the advised method is invoked, after it is invoked, both before and after its invocation and when an exception is thrown respectively. Whether applied via configuration or programmatically, the advised method has no knowledge of Spring.Net AOP or even that it has been advised.

PostSharp is another popular AOP framework for C# although one I do not have direct experience of. PostSharp, in contrast to Spring.Net AOP, performs its weaving at compile-time.

The Spring.Net documentation is very good at explaining AOP in general and Spring.Net’s implementation of AOP in particular and contains many examples. It is well worth a look even if you are not considering using the Spring.Net AOP framework.

Written by andrewlocatelliwoodcock

May 2, 2011 at 21:11

Posted in AOP, C#, Spring.Net

Tagged with , , ,

3 Responses

Subscribe to comments with RSS.

  1. great AOP Aspect oriented programming


    December 19, 2011 at 04:39

  2. Very interesting. Thanks for sharing. I’d heard about AOP in a few times recently, but the phrase was a bit confusing to me so a concrete, logging use-case such was helpful to visualise the advantages. Would it be comparable to the use of events/hooks like you’d see in some frameworks, but a bit more flexible/decoupled? Or am I still a little off target?

    I’m googling (for PHP examples) and I see one framework (FLOW) implements it with docblock annotations. Reminds me of Symfony2, which uses anotations for lots and lots of stuff.

    In any case, it sounds like a useful concept!

    • Hi Darragh,

      glad you found the article interesting!

      It is indeed similar in concept to events / hooks in that things happen and we can optionally listen for those events and then execute further code based on them. With AOP however, the developer doesn’t need to code the wiring, just declare what happens when a certain event happens and the developer also doesn’t need to explicitly code to trigger each event – the AOP framework handles that. Different AOP frameworks are implemented in different ways: some are pre-compiled and pre-bound to the executing code, whilst others like Spring.Net AOP are “wired up” at runtime. Pre-binding is more performant in general but runtime binding gives you more flexibility so you can change behaviour without having to release a new build.

      Where AOP really wins is in situations where you have two types of things that need to happen but don’t logically belong together: such as logging in my example. Another good example of where you could use AOP would be applying security to that example: checking user credentials, etc. The only disadvantage there is that if we are doing runtime binding, we don’t know definitively that there is actually anything being applied which would be a real problem for security solutions!



      June 6, 2012 at 11:34

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: