Archive

Posts Tagged ‘AOP’

Aspect Oriented Programming

November 27, 2010 3 comments

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.

%d bloggers like this: