Aspect-Oriented Programming

As I build up the next version of my Carbon framework, I have been researching everything and anything that might help make my life and my teammates’ lives easier.  To that end, I hit upon Aspect-Oriented Programming (again).  I had seen it before but for whatever reason it failed to resonate with me.  This time, I hit a power chord by way of PostSharp.

AOP is a way to separate scaffolding code from your business logic code.   Simple things like support for INotifyPropertyChanged can be removed from your objects and replaced with the [NotifyPropertyChanged] attribute.  In a security scenario, you can return a empty set or throw a permissions exception BEFORE a method executes.  In a caching scenario, you can review the method arguments and return the cached value it is already exists.  If it doesn’t grab the returned value post-method execution and add it to your cache for the next iteration.  The list goes on…  And it isn’t all that hard to write the aspect attributes to deliver the required functionality.  The best part is that you can override or ignore the aspects at runtime.  So you can leverage them AND ignore them with equal abandon.

If you read between the lines a little bit, you’ll realize I am talking about cross-cutting concerns.  (Microsoft Application Architecture Guide: Cross-Cutting Concerns)  Let’s be honest.  Dealing with cross-cutting concerns can be a serious pain.  Even realizing that you are fighting a cross-cutting concern is a challenge in itself (which is why I keep the MS list of CCCs on my desk at all times).  I know what they are and still forget to put 2 and 2 together in the moment.

Finally getting my brain wrapped around AOP and finding a quality toolset has really helped me move forward.  My code has gotten much simpler and cleaner as a result of AOP.  I can focus on the real problems I need to solve instead of the minutia around the problem.

Yes, there is a learning curve. But… It might be worth the effort. I know it has been for me.   Watch the PostSharp videos.  I think they are well worth the effort, even if is doesn’t fit your current needs.  I’d start with these 3.

You may already be using AOP

Call this instead: Intercepting Methods

Before and After: Boundary Aspects

Below is a little demo code I wrote to prove out what AOP offers.  This class is the model in a very simple MVVM app.  Changes to the widget are reflected in the UI without any INotifyPropertyChange code inside the Widget class.  Also everything is logged so I can see all of the get/set operations and the method calls.  Since this is in the aspect logger, I can change the logging level in one place and affect the entire app.  Recordable adds undo/redo support, again with no added code.

Pretty cool stuff if you ask me.

using AopDemo.Infrastructure.Aspects;
using PostSharp.Patterns.Collections;
using PostSharp.Patterns.Model;
using PostSharp.Patterns.Recording;

namespace AopDemo.Business.Domain
  public class Widget
    public string Name { get; set; }
    [Child] public AdvisableCollection Components { get; set; }

    public Widget()
      Components = new AdvisableCollection();

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.