Home > Uncategorized > Aspect Oriented Programming

Aspect Oriented Programming

Aspect Oriented Programming or AOP as it is so-called is an interesting technique to employ cross-cutting concerns such as logging, exception handling, security and others into your applications with hardly any effort at all.

AOP vendors such as SharpCrafters use an interesting technique at build time to ‘weave’ aspect code in with your methods. The result is that your methods are in a sense altered to incorporate these ‘Aspects’.

For example consider the proverbial ‘Foo’ method…

public void Foo()
{
     // Do something here
}

Now consider that you have the need to log when you are entering and exiting from the method. You could add the following code…

public void Foo()
{
     Trace.TraceInformation("Entering the Foo method.")
     // Do something here
     Trace.TraceInformation("Exiting the Foo method.")
}

This code works well if you need information about this one specific method. But, what if you need this information for all methods of a class? Writing this code is not only tedious, it detracts from code readability. Now imagine that you want this level of information on several classes, perhaps the entire project.

Enter Aspect Oriented Programming and a product such as PostSharp. To accomplish the logging capability at the method level, you would simply add an attribute as so…

[Trace]
public void Foo()
{
     // Do something here
}

[Trace] is an Aspect. Aspects are classes that you write in order to execute code within the boundaries of the method. In this example, code was written to perform some action on entry and another prior to exiting the method.

As mentioned earlier, you could apply this Aspect to the entire class or even an assembly with a single line of code…

[assembly: Trace( AttributeTargetTypes="SomeApp.YourBusinessRules.*",
  AttributeTargetMemberAttributes = AttributeTargetElements.Public )]

This works because a product like PostSharp uses a post compilation step to inject code into the IL. The code can be seen with a decompiler product such as Redgate Reflector.

If you’re interested in serious logging and performance monitoring you can combine the power of PostSharp with a product like Gibraltar for amazing results with almost no effort at all.

AOP – The Other Side of the Coin

If your thinking that you don’t want post compile code to be modifying the compiler-generated IL, you’re not alone. It is probably the single biggest argument against utilizing this technology. My personal opinion is that I consider many variables such as the application’s life-cycle. Is it a mature piece of code, is it legacy, or are we beginning a new project?

Certainly it is a compelling story to be able to gain much-needed cross-cutting concerns that were left out of a legacy code base with such little effort. In fact, it could even extend the life of the application dramatically.

However, if I’m starting a project from scratch, I tend to look at other alternatives such as code generation or policy injection with Microsoft Unity.

Summary

AOP is a very interesting technology that can yield almost immediate benefits with very little effort. Like any other pattern or technology, it has a time and place and you as the architect should weigh the risks and benefits before a single line of code is written.

  1. November 27, 2010 at 1:35 pm

    John,

    Thank you for blogging about AOP.

    Can you elaborate your argument against MSIL post-compile compilation? I haven’t seen a single valid rational argument, unless the fact that build is slower. Unfortunately, without arguments, the discussion remains irrational, and we’re not going to make much progress.

    Thanks!

    -gael

    • November 27, 2010 at 2:08 pm

      Gael,

      I think that the issue for most, is that they have to trust the capabilities of an outside party to write the MSIL. The argument may seem irrational to you because you know the excellence of your company’s capabilities. However, I’m sure that you can respect the need to verify code quality.

      Please know that I’m not questioning the PostSharp code quality in the least, but for most orgainizations peeking into MSIL is outside of their skill set. They therefore, have to take a leap of faith and for some, that is difficult to do.

  2. November 27, 2010 at 2:32 pm

    Thanks! How can people build trust in MSIL rewriting tools?

    As with any piece of software (whether it’s a compiler, a third-party library, or your own code): by verification and testing.

    Verification can be done using PEVERIFY (calling it is a part of PostSharp unit tests, of course). Testing a post-compiled program does not differ from testing any other program: unit testing is the key.

    Emitting correct MSIL is indeed very complex, especially in “edge” situations. A large parts of PostSharp pre-release bugs are indeed MSIL generation bugs, but these bugs have virtually disappeared.

  1. No trackbacks yet.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: