I've written a lot of AOP demos, given a lot of presentations on it (AOP For You and Me and The Class That Knew Too Much), and I even wrote a book about AOP in .NET. These aspects are all great places to start, but I thought I would take it a little deeper in a blog post series, detailing a real aspect I'm using in a real project, how I built it, and the reasoning behind the decisions I make. Because this is a much more practical example, this aspect is not generally applicable. You can't just drop it in to your project without tailoring it a bit. (If you are interested in those types of aspects, PostSharp has custom design patterns, ready for you to use today).

I'm only going to show you the basics of the aspect right now, and I'll build it up and add to it as this blog post series goes along. Note that this is an active project, and therefore it's still a work in progress. Part of the reason I'm doing this series is to help me get some real feedback!

My goal with this aspect is add error handling to my service layer. This service layer sits between my UI layer (an ASP.NET MVC application) and my data layer (which uses Dapper on a SQL Server database). When this aspect is done, it should:

• Catch exceptions
• Log (most) exceptions
• Ensure that a useful/helpful/friendly error message is given to the UI, instead of bubbling up the exception
• Make sure the service method returns something useful, if it's meant to return something

As an aspect, then, I can apply this to every public service method so that I don't have to worry about writing it over and over, and I don't have to worry about forgetting to add it to new service methods.

Let's start easy with a basic shell of an aspect:

I'm using MethodInterceptionAspect. I guess I could use OnMethodBoundaryAspect instead (or even OnExceptionAspect), since most of the code I'm going to write is going to end up being in that "catch" block. But let's just stick with this for now, and consider changing later (because of how PostSharp's API is structured, I know that this won't be very difficult).

Notice that there are two attributes on this aspect.

• [Serializable] - this is required by PostSharp, since PostSharp instantiates and serializes aspects at compile time.
• [MulticastAttributeUsage] - this is me telling PostSharp that I want to be able to multicast this aspect to public methods (see Aspects.cs below)

As it stands right now, this is not a good aspect, since it will just be swallowing all the exceptions. But it's as good as place to start as any, especially if you aren't familiar with AOP/PostSharp.

I'll also create another file in my project called Aspects.cs, which will contain assemly attributes so that I can apply this aspect to every method in the namespace where I put all my services.

I put an AspectPriority of "10" on it because I actually have another aspect in my project that I use to manage SQL transactions that has a priority of "20". I want the exception handling aspect to be the highest priority (lowest number).

Make sure you understand what's going on here before continuing. If not, you may want to review those presentations I linked to, check out the PostSharp documentation, or maybe check out my PostSharp Live webinar series.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• Tainted Love as played on 13 noisy floppy and 1 hard disk drives.
• ConduitJS is a "targeted AOP" framework for JavaScript
• Couldn't get enough Pete last week, eh? He wrote another blog post about Parameter Checking with Postsharp
• Check out this book on the Mikado Method of refactoring. I'm not familiar with it yet, but looks interesting.
• Using RealProxy for AOP

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

I was recently updating an ASP.NET project from MVC 4 to MVC 5 and I ran into some issues while compiling. The PostSharp post-compiler was complaining that it couldn't find a 4.0.0.0 version of an assembly.

I had the correct bindingRedirects in the Web.Config. I'm not completely clear on how and why bindingRedirects work, but as I understand it, this will redirect the compiler looking for a certain version of an assembly to another version of an assembly. Something like this:

I wasn't the first to run into this issue: I came across a similar question in the PostSharp support forums. PostSharp needs to be told where to look for the bindingRedirect confirmation (since PostSharp isn't specific to the web, the configuration could conceiveably be in app.config, web.config, or some other config file). So, I merely needed to add a PostSharpHostConfigurationFile property to the csproj file, as shown in the PostSharp documentation. After that, everything worked fine.

One of the problems with object-oriented programming that AOP aims to solve is excessive boilerplate. And there's no more stark example of excessive boilerplate than the use of INotifyPropertyChanged.

NotifyPropertyWeaver is a tool that adds an MSBuild task to your project. It will find all your implementations of INotifyPropertyChanged and rewrite the properties to do all the notification code for you. So you don't have to worry about mistyping that property name string, and you don't have to worry about refactoring when you rename or remove properties.

In this code example below, the first file is a typical implementation of INotifyPropertyChanged, done entirely by hand. Notice all the noise and duplication: explicit backing properties, multiple calls to NotifyPropertyChanged to account for the derived property, the use of a string that exactly matches the property names. And this is a class with only three properties. Imagine if you had a whole bunch more properties, and imagine the maintenance problem to add/remove/change one of the derived properties!

The second file is an example of how you would do the exact same thing using NotifyPropertyWeaver. You don't have to write the NotifyPropertyChanged method, or call it in the setters, or write backing properties. This class is so much easier to read and maintain. The third file is actually a look at the class after it's been compiled, run through NotifyPropertyWeaver, and then disassembled with Telerik's JustDecompile. Look familiar? It's almost exactly the same as the hand-coded implementation.

And finally, the fourth file is the change that will be made to your project file when you add NotifyPropertyWeaver with NuGet. It calls a task that uses Mono.Cecil to rewrite the code for you. You don't need to reference the build task DLL in your project.

NotifyPropertyWeaver is a tool that does a single task, but this approach (an MSBuild post-compiler task) can be used to implement other AOP features. Fody is a tool by the creator of NotifyPropertyWeaver to do just that.

Week #2 is coming to an end here at CrossCuttingConcerns, which means it's time for another link dump post.

• LIDNUG (Linked-in .NET user group) recently posted video of Gael Fraiteur at their user group meeting. This was recorded in November 2010, so it's a bit behind the times as far as PostSharp goes, but it's still an informative video.
• Here's a white paper comparing AOP to composition filters (CF). I've not heard of CF before this paper, but it seems that like AOP, CF aims to address the same limitations with cross-cutting concerns that AOP does. (PDF link)
• Taking the Single Responsibility Principle (SRP) seriously. A deep dive into SRP, and just what is a "responsibility" anyway?
• Another white paper, but this one is about an interesting use case of AOP. It's based on a project to "trace" an application: not in the traditional developer sense of tracing through the code, but rather tracing a user's actions as she uses the interface to a system. And then using that information for later analysis (perhaps a usability study?).
• A blog post from Kristijan Rebernišak about using AOP to check user permissions: he uses Google Guice with AOPAlliance.
• Chad England has started a blog post series on AOP with PostSharp.

Thanks for reading, and please leave a comment or use the contact link above if there's something you'd like to see covered here on CrossCuttingConcerns.com (or if you have something to say and want it published here).