In your WCF service methods, you should always provide proper exception handling. The exception handling code is almost always the same, so it’s usually just copy/pasted in each method. Here’s an example of a typical service method:

That’s a lot of code, even though only ONE line will differ from the other service methods in this service. Let’s clean up this mess, shall we? Exception handling is a cross cutting concern so we might as well put it in one place (at least, one place for each different kind of exception handling that you need). We’ll use PostSharp to define an ApplyServiceExceptionHandling aspect:

And now we can modify the earlier service method to this:

That’s a lot cleaner than the previous version right? Actually, this service has more than one service method so we’re better off moving the ApplyServiceExceptionHandling attribute to the class level instead of the method level:

now we can get rid of all of the exception handling code in each service method, but each one will have exception handling applied to it because the exception handling aspect is applied to the class, and thus, to each method of that class. And if you need to modify your exception handling (to handle TargetInvocationExceptions with BusinessExceptions as InnerExceptions for instance?) you’d only have to do this in one place.

Btw, i’m aware of WCF’s IErrorHandler interface (which allows you to handle exceptions in a general manner as well)… i just don’t like it

A little while ago, i talked about adding behavior to components using Windsor’s Interceptors. I wanted to try something similar with PostSharp, which is a very powerful Aspect Oriented Programming framework for the .NET world. Discussing everything PostSharp can do (which is a lot) is way beyond the scope of this post, so we’ll just focus on what i’m trying to do, and how PostSharp helps us with that.

In the previous post, i used a logging example… i didn’t want logging code mixed up with my real code, so i used a Windsor Interceptor to intercept calls to classes that i had configured to be logged. The interceptor would then log before and after the method calls were executed. In this post we’ll do something very similar, but a bit more advanced. We’re gonna write some tracing logic that will write a trace statement when the method is entered, along with the parameter values for each of its parameters. Then after the original method has executed, we’ll write a trace statement to indicate that we have left the method, and we’ll display the return value of the method as well, if there is one. That kind of tracing information can be very valuable, but writing that code is extremely tedious work. Nobody wants to do that, right? I sure as hell don’t.

We’ll use the following simple class as an example:

This calculator has a pretty limited feature-set, but we don’t need anything more for this example. Ok, so how do we add the tracing code without actually adding it to this code? We can just compile the code, and then we can have PostSharp inject some extra code to the compiled code. Sounds pretty hard, right? It is. But PostSharp Laos is a small framework that runs on top of PostSharp and it takes care of the hard work for you. PostSharp Laos offers some base classes which make it really easy for you to write your aspects (if you don’t understand that term, you should have clicked on the aspect oriented programming link earlier in the post ;)). There are a couple of approaches you can choose between, and they all have their pro’s and con’s. A nice overview of the different kinds of aspects you can inherit from can be found here. For this example, we’ll use the OnMethodInvocationAspect base class. This basically intercepts calls to methods and allows you to add some logic.

So what would our tracing aspect look like? How about this:

So now we have a trace aspect which shows some valuable information about method calls… it shows when the method is entered, which parameters were passed in, when we leave the method and what the return value is.

So how do we apply this aspect to our code? We modify the definition of the Calculator class like this:

And then we compile… Well actually you have to add something to your project file so PostSharp can modify the compiled code, but since that’s covered nicely in the PostSharp documentation we’ll skip that step in this post. Anyways, when you compile this, you’ll get the following build output:

If we use the calculator class like this:

We’ll get the following trace output:

How nice is that? With some exception handling, better formatting and some clever indenting, this tracing aspect could be the only tracing code you’ll ever need from now on

So how does it work? Well, we can look at the compiled code in reflector for that. Here’s how the Add method looks like after PostSharp modified the code:

As you can see, it’s renamed our Add method to ~Add, and it added another Add method which calls the OnInvocation method of our TraceAspect class with the correct MethodInvocationEventArgs. Pretty cool stuff IMO. Oh and btw, if you’re debugging this code in Visual Studio, you still only see your own code, with the original method name. While you step through it, the code runs just like it normally would, and the applied aspects are also executed. Very impressive.

If you use the OnMethodBoundaryAspect instead of the OnMethodInvocationAspect, you’ll see that the modified code doesn’t replace your method like it did here. But it will add a lot of extra code to it as well. All in all, there are a lot of possibilities here. If i’m not mistaken, i can now even use our TraceAspect and use it on classes in other assemblies, even if i don’t have access to them. We’ll look into that in a future post

Anyway, PostSharp is an extremely impressive piece of software which provides a whole lot of power and flexibility. You should definitely check it out and play around with it… i know i’m gonna be experimenting with it more often to see what kind of weird and cool stuff we can make it do

The Windsor container makes it quite easy to add behavior to components, without having to modify their implementation. This could be useful in many scenario’s. Suppose you need to log whenever a method from our OrderRepository class is called. But we should be able to turn the logging on and off whenever we want. Preferably, without having to modify the code all the time. Now, you could easily write a logger class that checks for a configuration setting and only logs when needed. This approach would definitely work. But then there’s logging code all over the OrderRepository class and in most cases, it’s not even necessary since they only want to be able to log under certain circumstances. Should the OrderRepository class really care about the logging? Why litter the code with logging statements?

If you’re using the Windsor container, you could easily add logging behavior to the OrderRepository class without having to change any of the existing code. Windsor has this concept of Interceptors. Basically you can assign an interceptor to any component and you can plug in your custom behavior when the component is called. Lets get into an example… Since logging is such a common requirement, we decided to put it in one class instead of littering our entire code base with logging statements. So we wrote the following class:

This class implements the IInterceptor interface by implementing the Intercept method. When that method is called we simply construct the full method name, log when we enter the method, call the original method and then we log again when we leave the method. Nothing more, nothing less. Also notice how the LoggingInterceptor has a dependency on an ILogger instance. That instance will be injected by the container as well.

So first of all, we need to define the ILogger and LoggingInterceptor components:

Right… so now we need to add this behavior to the OrderRepository class. This only requires modifying the registration of the IOrderRepository component:

What we basically did was tell Windsor that whenever an IOrderRepository is requested, we should return an instance of OrderRepository and each time a method of that instance is called, it needs to be intercepted by our LoggingInterceptor.

So if we simply call the IOrderRepository methods like this (obviously these are dummy calls without real parameters and we’re also ignoring return values):

The following output is logged:

21:53:42.6942016 Entering method: Components.OrderRepository.GetAll
21:53:42.6942016 Leaving mehod: Components.OrderRepository.GetAll
21:53:42.6942016 Entering method: Components.OrderRepository.FindOne
21:53:42.6942016 Leaving mehod: Components.OrderRepository.FindOne
21:53:42.6942016 Entering method: Components.OrderRepository.FindMany
21:53:42.6942016 Leaving mehod: Components.OrderRepository.FindMany
21:53:42.7042160 Entering method: Components.OrderRepository.GetById
21:53:42.7042160 Leaving mehod: Components.OrderRepository.GetById
21:53:42.7042160 Entering method: Components.OrderRepository.Store
21:53:42.7042160 Leaving mehod: Components.OrderRepository.Store

And we didn’t have to change the OrderRepository implementation. In fact, we can use our LoggingInterceptor wherever we like, as long as the component to be logged is registered with Windsor. And we can easily switch between logging or no logging by switching config files.

Obviously, this was just a really simple example but i hope you realize how powerful this technique is and how far you can go with this.