My weekly Code Project newsletter had a link to a submission which talked about, and rated various Aspect Orientated Programming (AOP) frameworks for .Net. While I’ve heard about AOP in the past, I haven’t looked into much. What got me off the side lines, was that one of the .Net AOP frameworks, Post Sharp, lists support for the Compact Framework and Silverlight. In my experience, it is rare to see stuff that actually supports the compact framework, so this is a welcome change, however I have not tested it out yet.

Before I dive into Post Sharp anymore then I have, I wanted to read up a bit on AOP. WikiPedia has a good article explaining the AOP using AspectJ as the example language. PostSharp itself has a an article that focuses on the .Net Framework as well.

What is Aspect Orientated Programming (AOP)?

• AOP increases modularity by allowing the separation of cross-cutting concerns
• A concern is a cohesive area of functionality (think encapsulation).
• Cross-Cutting concerns are those concerns which are used in multiple concerns
• Logging is the most typical example of a cross-cutting concern. It itself is a concern (encapsulated functionality), that is used everywhere in your program.

Examples of Cross-Cutting Concerns

• Logging
• Exception Handling
• Tracking is dirty on fields
• Auditing
• Security
• Transactions

How does it work (based on Post Sharp)

• Implement cross-cutting concerns as classes creating attributes (implementing various interfaces in Post Sharp)
• Decorate your code using your attributes. Attributes can be added at the method, field, class and assembly level. At the class and assembly level you can specify a filter specify which methods or classes to work on.
• When you compile, Post Sharp performs post build processing injecting code into your compile MSIL, producing modified MSIL as the final output.

AOP Frameworks

• See the Implementations section of the Wikipedia article.

Performance

I was originally under the impression that by injecting code at compile time, there would be no performance hit at run time. This is not true, at least in PostSharp using the simple performance test from the user provided samples.

The simple performance test sample shows that AOP using Post Sharp incurs a variable performance hit. Running the sample application multiple times shows the first time the post sharp code is hit (view the complied .exe in reflector) it takes 73ms, and then this drops down to 14 ms, compared to 4 ms for the non PostSharp code. On subsequent runs, the first access of the post sharp code takes ~21ms and then drops down to 14ms, while the non PostSharp code remains at 4ms.

The sample in question uses the works on a field in a class. The aspect (attribute code) is required to cast an object passed in by the event args to a string. Perhaps generics could help with performance by eliminating the cast?

Final Thoughts

AOP and PostSharp look like very powerful tools that I would like to take advantage of. Learning from my past mistakes, I need to make sure that I take the time to understand these tools and use them where appropriate and not go overboard with their use. I think a good first step would be to find, or write some examples that implement some basic AOP functionality covering all of the cross-cutting concerns identified above.

The only complaint I have so far is that you have to either install PostSharp on your computer, or manually edit every project file that needs post processing. This seems a little heavy handed, but I’m willing to consider it a fair tradeoff. It just makes it hard to do a strictly x-copy deployment of a project/solution.

I’ve also been reading up on software architecture, including topics on Separation of Concerns and Loose Coupling. I think it is obvious that AOP can help with the separation of concerns (it’s pretty much stated in the definition). I also get the feeling that it could help with loose coupling, but I haven't seen a good example on that yet. All the examples I have seen would require tight coupling of your aspects (attributes) to something like log4net (in the logging example).

Finally, I will need to continue to evaluate performance to determine if it’s a fair tradeoff with increased maintainability of code. I am most concerned on the compact framework side of things, as the processing power that those apps run on is not as great as their desktop counterparts. This is not a knock on PostSharp, but just something to be aware of.