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.

• Part 2 of using PostSharp to implement Undo/Redo. You will not believe how easy it is.
• There's also a Part 3 of using PostSharp to implement Undo/Redo.
• And guess what, there's a Part 4 of using PostSharp to implement Undo/Redo.
• I submitted something from "Look Around You" to the Moviecode tumblr, and it's in BASIC.
• I've heard from multiple sources now that SVG icons are becoming a trend. Check out geomicons.
• In my web development class at Capital University, a guest lecturer (Jon Plante) asked the students to go through an exercise of trying to name the website after taking away all the text and graphics. Dedesign the Web is just like that.

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

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.

• 2013 Stack Overflow User Survey. 10% of users are working remotely full-time. I don't think they asked the question last year, but if they did, my bet is that percentage has gone up.
• Samuel L. Jackson does not like it, but Dennis Nedry loves Jurassic Systems.
• Add Undo/Redo to your application with PostSharp, using the Recordable Pattern.
• A way to deal with the Android slide-out menu and screen rotation.

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

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.

• If you are having trouble understanding how SQL joins work, check out this diagram on SQL joins for a useful visualization.
• Sometimes it's hard keeping up with security issues with all the software you have installed on your computer(s). I've been using the (free) Secunia PSI (Personal Software Inspector) for years--it keeps me up-to-date on the latest security exploits and can automatically update your software for you.
• TwitchPlaysPokemon - an experiment to "crowdsource" gameplay. Imagine 60,000+ people using the same controller. This is interesting for its entertainment value, of course, but also a study of emergence. A critic of emergence might point to this as a failure. But I think it demonstrates that emergence might not work if there aren't any real constraints. If each user was limited to maybe one command (per hour, maybe), or there was some sort of majority vote on each command, or some constraint like that, I think the resultant gameplay would be much more interesting. As it stands now, it's probably not any different from just randomly hitting buttons. EDIT: As of today, there is a "democracy/anarchy" feature that allows users to introduce constraints, which appears to be making the game run much smoother.
• Maybe RSS is going out of style, but I still use it every day. If you wish a web site had an RSS feed, but it doesn't, you might want to check out Feed43 (Feed for Free). It's a scraping tool that I use from time to time when nothing else is available. And remember that Cross Cutting Concerns has an RSS feed.
• More Pete on Software, as he continues his blog series on PostSharp. This time he explores the automated design patterns feature for background threading that comes with the full commercial version of PostSharp.

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

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.