Last week I released DomainAspects 2.0 without many details other than its general features. In this post and future posts, I’m going to delve into the details one area or feature at a time. My purpose is to help you understand how each piece works and provide examples of how you might use the library or the code in your own projects.
The few aspect oriented programming (AOP) languages and frameworks that I have looked at seem to me to be unwieldy and unnecessarily intrusive in the the daily workflow of an application developer, cluttering up the code and creating cumbersome dependencies on the AOP construct itself. Fortunately there is a cleaner alternative to AOP languages found in the inversion of control (IoC) containers we so commonly use for dependency injection in order to enjoy the benefits of SOLID Design: the Interceptor.
Interception is supported by many of the IoC libraries. I’ve used Unity a little but most of my experience is with Castle Windsor, so of course, I prefer Windsor. I also prefer Windsor’s interception approach because I find it easier. If you are a Unity user, take a look at Dino Esposito’s Unity Interception article on MSDN. You an see for yourself that the Unity IInterceptionBehavior implementation is relatively more complex than Windsor’s IInteceptor:
public interface IInterceptor
{
void Intercept(IInvocation invocation);
}
In DomainAspects, I wanted my Interceptor to handle logging and exception handling, which I like to call “auditing”, probably the most common of the cross cutting concerns handled by AOP. I also wanted the Interceptor to handle authorization security. But I wanted to have a simple Interceptor class that would have its “auditor” and “authorization” dependencies injected by the same container. Each dependency would handle its specific responsibilities.
Here’s the Windsor fluent configuration code for each of these. Note the first component is the IPrincipalProvider which is a dependency of the IOperationAuthorizer implementation. I then register the components for the authorizer and the auditor. The last component configured by the DomainAspects ServiceFactory class is the OperationInterceptor.
_container.Register(
Component.For<IPrincipalProvider>()
.ImplementedBy(_principalProviderType)
.Named("PrincipalProvider")
.LifeStyle.Transient,
Component.For<IOperationAuthorizer>()
.ImplementedBy(_operationAuthorizerType)
.Named("OperationAuthorizer")
.LifeStyle.Transient,
Component.For<IOperationAuditor>()
.ImplementedBy(_operationAuditorType)
.Named("OperationAuditor")
.LifeStyle.Transient,
Component.For<OperationInterceptor>()
.Named("OperationInterceptor")
.LifeStyle.Transient);
When the DomainAspects ServiceFactory’s Create method is called, if the service has not already been registered with the Windsor container, it will register the container and wrap it with the Interceptor we have just configured using Windsor’s fluent interface. Here’s the code:
_container.Register(
Component.For(interfaceType)
.ImplementedBy(implementedByType)
.Named(implementedByType.Name)
.Interceptors(InterceptorReference.ForKey("OperationInterceptor")).Anywhere
.LifeStyle.PerThread);
Note that the .Interceptors method takes a params of InterceptorReference objects. So like Unity, you can chain interception. Unlike Unity, the chaining occurs automatically for you in sequence of the array. Your IInterceptor implementation does not require you to be concerned with wiring up the chain as does the Unity IInterceptorBehavior.
Now take a look at the relatively simple, application requirement focused OperationInterceptor class which implements the Windsor IInterceptor interface with a single method and depends on the container to inject its two dependencies. The code in the interceptor class here just handles the business case of examining the class and method being intercepted for attributes that will require action by one or both of its dependencies.
public class OperationInterceptor : IInterceptor
{
private IOperationAuditor auditor;
private IOperationAuthorizer authorizer;
public OperationInterceptor(IOperationAuditor opAuditor, IOperationAuthorizer opAuthorizer)
{
auditor = opAuditor;
authorizer = opAuthorizer;
}
public void Intercept(IInvocation invocation)
{
AutoLogAttribute autoLogAttribute = null;
AuthorizeAttribute authorizeAttribute = null;
var methodInfo = invocation.MethodInvocationTarget;
object invokedKey = null;
try
{
//find AutoLogAttribute
autoLogAttribute = ((AutoLogAttribute[])methodInfo
.GetCustomAttributes(typeof(AutoLogAttribute), true))
.FirstOrDefault();
if (null == autoLogAttribute) //try class level
autoLogAttribute = ((AutoLogAttribute[])methodInfo.DeclaringType
.GetCustomAttributes(typeof(AutoLogAttribute), true))
.FirstOrDefault();
if (null != autoLogAttribute && null != auditor)
{
//log invocation
auditor.LogOperationInvoked(methodInfo,
invocation.Arguments,
invocation.GenericArguments,
out invokedKey);
}
//find AuthorizeAttribute
authorizeAttribute = ((AuthorizeAttribute[])methodInfo
.GetCustomAttributes(typeof(AuthorizeAttribute), true))
.FirstOrDefault();
if (null == autoLogAttribute) //try class level
authorizeAttribute = ((AuthorizeAttribute[])methodInfo.DeclaringType
.GetCustomAttributes(typeof(AuthorizeAttribute), true))
.FirstOrDefault();
if (null != authorizeAttribute && null != authorizer)
{
//authorize
authorizer.Authorize(methodInfo, invocation.Arguments, invocation.GenericArguments);
}
//proceed with invocation
invocation.Proceed();
}
catch(Exception e)
{
//log exception and throw
if (null != autoLogAttribute && null != auditor)
{
auditor.LogOperationException(invokedKey, methodInfo, e);
}
throw; //always throw to bubble up exception and preserve call stack
}
}
}
If you are considering aspect oriented programming or you need interception for another reason, I hope this post is helpful. If you are looking through the DomainAspects 2.0 library code, I hope this will help you understand how and why I’ve used Windsor’s IoC container and their interception facility.