In the previous post, we got the aspect to communicate with the service object by using args.Instance. But it only really works for one service: TerritoryService.

How can we get it to work with other services?

One approach would be to add a bunch of casts and if-statements:

I don't like that approach much. Another approach would be to create a base class that all our service classes would inherit from. I generally try to avoid this approach as much as possible, but I think it makes sense in this case. We could create an interface, like IHasValidationCallback, but let's take it one step further and create an abstract base class that already contains the implementation.

Now that the TerritorySerivce (and our other services) have a ServiceBase base class, we can update the aspect to use ServiceBase.

And there you have it: as long as all the services in the namespace inherit from ServiceBase, this will work.

So I think we're making progress, but let's review the issues from last time:

• This only works for ITerritoryService--what about the other services? We just addressed this one.
• Swallowing exceptions: we should at least be logging the exception, not just ignoring it.
• If the method has a return type, then it's returning null. If it's meant to return a reference type, that's probably fine, but what if it's returning a value type?
• What if it's returning a collection, and the UI assumes that it will get an empty collection instead of a null reference?
• Do we really want to return the exception message to the user?
• NEW ISSUE: What if I forget to use ServiceBase as a base class on a new service?

Yep, we fixed one issue, but we really just shifted the problem to a base class that could easily be overlooked. Next time, let's see if we can get PostSharp to help us with that.

In the last post, I laid out the bare essentials of an error handling aspect for my service layer.

Before I proceed further with the aspect, let's examine the layer right above the service layer: the UI layer. I'm using ASP.NET MVC.

With ASP.NET MVC, there is a concept of ModelState, which holds information about validations performed during model binding, and is also used by the controller to convey error information to the view (through the Html.ValidationSummary helper, for instance). I'm already using ModelState to convey simple validation errors; I'd like to use it to convey any errors that the service layer might encounter. There are many ways to approach this; I've chosen the "callback" approach--passing a lambda to the service layer in order to communicate error information from the service layer up to the UI layer. Here's the basics:

Dependency injection gives me an object that implements the ITerritoryService interface, but I have to take one more step and pass that service the lambda x => ModelState.AddModelError("", x) in the controller instructor. This is because ModelState doesn't actually get instantiated until the controller does (so I can't pass it to the service object any sooner).

Now, when there's an exception in Territory service, I can simply use this "callback" to add an error to the ModelState. (Side note: a benefit to this approach is that it does not couple TerritoryService to my UI: if I wanted to use this service with another UI--say, WebAPI or WebForms--then I would simply have to pass in a different lambda).

Let's get the aspect to use that callback.

By using args.Instance, we can get a reference to the object in which the method resides. If that object can be cast to ITerritoryService, then we can simply call AddModelError. This works great: now anytime there's an exception in TerritoryService, it will be added as an error to ModelState and displayed to the user.

But clearly there are still issues here:

• This only works for ITerritoryService--what about the other services?
• Swallowing exceptions: we should at least be logging the exception, not just ignoring it.
• If the method has a return type, then it's returning null. If it's meant to return a reference type, that's probably fine, but what if it's returning a value type?
• What if it's returning a collection, and the UI assumes that it will get an empty collection instead of a null reference?
• Do we really want to show the exception message to the user?

Next time, we'll start addressing the first issue, and figure out a way to make this aspect more generic.

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.