AOP may sound like this big high-falutin' term that's way too complicated, but guess what: you may already be using AOP and you don't even know it.

Do you using ASP.NET MVC? Ever used an ActionFilter? Congratulations, you have used aspect-oriented programming. If you are using MVC and haven't used an ActionFilter yet, read on, because you may want to start!

Writing an ActionFilter is very similar to writing a PostSharp aspect: you create a new class that inherits from a base class (ActionFilterAttribute), and then you override one or more methods depending on what you want the ActionFilter to do.  You apply the aspect to a method or entire class with an attribute. Unlike PostSharp, this form of AOP does not involve a post-compile step. The filtering takes place at runtime, and is invoked by the MVC framework. This means that if you are writing a unit test against the controller action, that test will not trigger the ActionFilter.

I'm going to be blogging some more details about what you can do with each of these, but when you are creating a class that inherits from ActionFilterAttribute, there are 4 methods that you can override 1 or more of:

• OnActionExecuting - runs before the affected action
• OnActionExecuted - runs after the affected action
• OnResultExecuting - runs before the result of the action runs
• OnResultExecuted - runs after the result of the action runs

If you use the [Authorize] attribute in MVC, then you are using an ActionFilter that's been pre-written for you (technically AuthorizeAttribute inherits from FilterAttribute, but it's the same principle). Instead of checking the User.Identity inside every one of your Controller actions, you can just slap the [Authorize] attribute on it and it will keep that cross-cutting concern encapsulated away from the rest of your Controller logic.

There's a whole conference dedicated to aspect-oriented programming. The AOSD (Aspect-Oriented Software Development) conference is put on by the AOSA (Aspect-Oriented Software Association).

The 2012 conference is on March 25-30, in Potsdam, Germany. A five day conference on AOP? Wowza. But wait, there's more. You can also attend FOAL (Foundations of Aspect-Oriented Languages) while you're there in Potsdam on March 26, where Eric Bodden will be keynoting.

All things considered, I'd really like to go, but I definitely can't.  Maybe next year decade, after I save up enough vacation days and learn some German?

I started doing some AOP screencasts for dimecasts.net some time ago. I had a roadmap in mind, but due to some unrelated events, I never got around to making the third one of these yet.

The first one is a pretty standard Hello World AOP 101 screencast that uses PostSharp: Getting Started with AOP Using PostSharp. 

The second one is called Working With Advanced Aspects, and just expands on some more PostSharp features around boundaries and interception.

I had definitely planned to do 2-3 more of these dimecasts, as sort of a way to give back to a site that helped me to learn some important tools and techniques in an efficient and convenient way.

So, I could continue with that plan, but if you have a suggestion as to what you would want to see in an AOP screencast, I'm all ears. Want to see some runtime AOP with Castle DynamicProxy? Or maybe some validation and initialization techniques with PostSharp? Or something else?

When deploying this site for the first time and actually telling people to come here, I learned that I had made a pretty big mistake. Appropriately (or perhaps tragically), I made a mistake in one of the cross-cutting concerns of my own site.

I am using StructureMap to wire up all my dependencies, and 90% of these dependencies are just done WithDefaultConventions. But there is one dependency, IDbConnection which I wired up by hand, like so:

If you can spot the mistake here, then congratulations, you are officially a better developer than me (which is no high accolade). Here's what I should have done:

And then, in Application_EndRequest, I just call ReleaseAndDisposeAllHttpScopedObjects() on ObjectFactory. This means each of the SqlConnections will be bound to a request, and then disposed of when the request is complete. Because I wasn't doing that before, each of the connections would stay open. I didn't notice this when developing the site, because I was continually rebuilding and redeploying.

This may not be strictly speaking AOP, but it's certainly a cross-cutting concern, as almost every request makes use of the IDbConnection to use Dapper, and using StructureMap to manage that dependency saves me from writing a bunch of boilerplate "new SqlConnection" in all my repositories.

Lesson learned: if this site was actually mission critical to a business, I would've been in hot water. I should've been testing with a larger number of requests over a longer running application in an environment similar to production. Fortunately, since I didn't have a bunch of repetitive boilerplate, it was very easy for me to make the fix, once I figured out what the problem was.

Thank you for visiting, and welcome to Cross Cutting Concerns.

I've been evangelizing AOP (and PostSharp) for a while now, so I thought it would make sense to create a focused blog around this topic instead of using my much broader mgroves.com blog, as well as give me some additional motiviation to increase the frequency of my blogging this year.

So, what can you expect to see on this site?  Well, a lot about AOP theory and tools, for sure.  But ultimately, the goal of AOP is to improve your code, help you follow SOLID principles, save you time, make your app easier to maintain, and generally make life easier for object-oriented programmers; part of learning about AOP means learning when not to use AOP.  While I mainly write C# and use PostSharp, this blog's charter is not limited to either of them.  I may, from time to time, dive into AOP for Java, PHP, Ruby, etc, as well as look at other .NET AOP tools like DynamicProxy, LinFu, etc.

Also, I'm the sole author for now, but if you are interested in writing guest posts or becoming a regular author here, I will certainly be interested in talking to you about that.

One more minor note about this site: this site is not running on a blog engine like Orchard or BlogEngine.net.  I tried a couple and ultimately found that I've been pretty spoiled on Wordpress and its impressive extensibility and customization options.  However, I've never written a blog site on .NET, so I made that one of my requirements. So I ended up writing my own blog engine.  Yes, I can hear you groaning and rolling your eyes.  If you see bugs or weirdness, this is probably why, so please feel free to call me out on it so I can fix it.  I also plan to open source it eventually (as if the world needs another blog engine).