Free Tools

Unity Community Contributions and Interception

Matthew Podwysocki — Fri, 11 Apr 2008 23:35:05 GMT

Now that Unity has been released into the wild, there has definitely been a bit of interest swirling around it. One of my key wants for a good IoC container is basic interception capabilities. My criteria for evaluating a container usually comes down to the following:

Configurability (XML, DSL, Code)
Dependency Resolution, usually opinionated
Lifetime Management (Per Thread, Pooled, Singleton, Transient, etc)
Extensibility for Interception

So, I realized that Unity was missing some of these things in the first go around. Since Unity was built on top of ObjectBuilder2, a next generation version of the often maligned ObjectBuilder which also included some sample DI containers and a flexible interception model. Today's post will cover that and a bit more. I realize that I still am working on a post of AOP in the Enterprise and Spring.NET which is coming soon.

Where We Are

But, before we begin today, let's see what we've already covered in the past:

Unity 1.0 Released into the Wild
Unity 1.0 released and available on MSDN. Unfortunately, registration is required...
IoC and Unity - Configuration Changes for the Better
Covers the configuration changes to allow for better parameterization for constructors
IoC and Unity - The Basics and Interception
Talking about the basics of IoC containers and the interception models
IoC Container, Unity and Breaking Changes Galore
Covers the breaking changes made from the old Unity drop to the new one
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
Managing instances and parameter mapping resolution
IoC and the Unity Application Block Once Again
Setter Injection versus Constructor Injection and PostSharp4Unity
IoC and the Unity Application Block - Going Deeper
Constructor Injection and comparing Unity with Castle Windsor
IoC and the Unity Application Block
Covering ObjectBuilder and Unity Application Block

Now that we've look at the history of this series, let's go ahead and get started.

Unity Contributions

Since Unity was released last Friday, there has been a community effort much like the ASP.NET MVC Contributions, MVCContrib, called Unity Community Contributions. This project is intended to fill in the gaps where the community feels that Unity can be extended, much like most other IoC containers. As I stated above, one of those crucial things that I thought was missing was taking the ObjectBuilder2 Interception model and applying it towards Unity. I wasn't interested as much in the Policy Injection Application Block, although nice, is a bit heavyweight for the basic operations I would like. Instead, the OB2 would suffice for most things that I'd want with a container. So, that led me to another topic...

ObjectBuilder2 Interception == Unity Interception?

Since I was particularly motivated to see the OB2 Interception model pushed into Unity, I decided to give it a go myself. For the most part, I was successful in a way, but I wasn't using the right extensibility model. From that point, I got in contact with Scott Densmore, a PM within the Patterns & Practices group and one of the authors of ObjectBuilder2 along with Brad Wilson. From that point, he was able to take the original OB2 Interception model and fit it nicely into the Unity extensibility model. The code is now available on the Unity Community Contributions and you can find those commits by Scott here.

So, let's take a look at what it entails. As I tell most people, you learn the most about the software with good unit, I mean behavioral tests where I can really grok the intent of the code much better than most documentation. I encourage most people to do the same. I'd rather stay away from those projects that don't have tests to back up their work.

Like I said before, ObjectBuilder2 had several ways of intercepting calls. There are several interception strategies worth mentioning:

Virtual Method interception
Interface Method interception
.NET Remoting interception (MarshalByRefObject)

From that, you have two ways of registering your interest for interception:

Intercept via code
Intercept via attributes

Now that we've laid down the basics, let's take a look at some of the unit tests. You'll notice that xUnit.net was used for the unit tests. Yes, I know, I've mentioned it a few times lately. Anyhow, let's look first at virtual method interception.

Before we get started on that, in order to perform interception, we need to implement the IInterceptionHandler interface. For the unit tests, this will be used to record the various actions that happened during the interception process. But you can imagine it to do any number of things such as logging, transaction management, security and so on. Any of those cross cutting concerns, really.

    public delegate IMethodReturn InovkeHandlerDelegate(IMethodInvocation call,

                                                        GetNextHandlerDelegate getNext);

    public delegate InovkeHandlerDelegate GetNextHandlerDelegate();

    public interface IInterceptionHandler

     {

        IMethodReturn Invoke(IMethodInvocation call,

                             GetNextHandlerDelegate getNext);

     }

 } 

   public class RecordingHandler : IInterceptionHandler

    {

        readonly string message;

        [InjectionConstructor]

        public RecordingHandler()

        {

            message = "";

        }

        public RecordingHandler(string message)

        {

            this.message = string.Format(" ({0})", message);

        }

        public IMethodReturn Invoke(IMethodInvocation call,

                                    GetNextHandlerDelegate getNext)

        {

            Recorder.Records.Add("Before Method" + message);

            IMethodReturn result = getNext().Invoke(call, getNext);

            Recorder.Records.Add("After Method" + message);

            return result;

        }

    }

We have the ability through the Invoke method to do things before the method as well as after. Should we need to modify values before the method is called, we can go ahead and do so. Now that we looked at that, let's get to some unit tests. First off, let's look at interception through just code. I like this approach as opposed to attributes due to not cluttering the domain model and making it more configurable at run time.

            [Fact]

            public void InterceptViaCode()

            {

                Recorder.Records.Clear();

                IUnityContainer container = new UnityContainer();

                container.AddNewExtension<InterceptionExtension>();

               container.Configure<IInterceptionConfiguration>().InterceptVirtual<SpyVirtual>
                   (typeof(SpyVirtual).GetMethod("InterceptedMethod"), new RecordingHandler());

                SpyVirtual obj = container.Resolve<SpyVirtual>();

                obj.InterceptedMethod();

                obj.NonInterceptedMethod();

                Assert.Equal(4, Recorder.Records.Count);

                Assert.Equal("Before Method", Recorder.Records[0]);

                Assert.Equal("In Method", Recorder.Records[1]);

                Assert.Equal("After Method", Recorder.Records[2]);

                Assert.Equal("In Non-Intercepted Method", Recorder.Records[3]);

            }

public classSpyVirtual

            {
public virtual void InterceptedMethod()

                {
Recorder.Records.Add("In Method");

                }

public void NonInterceptedMethod()

                {
Recorder.Records.Add("In Non-Intercepted Method");

                }

public virtual void ThrowsException()

                {
Recorder.Records.Add("In Method");
throw new Exception("This is my exception!");

                }

            }

As you see above, we can simply register our interest through the registration of the InterceptionExtension and then set up the configuration through the IInterceptionConfiguration. From that point, we then say which kind of interception we want whether it be virtual, remoting or interfaces. We specify the method we want to intercept by name.

You can also do the interception through the use of attributes. From this point, we need to decorate our methods with the attribute and the particular interception handler we want to use. We need to be aware of which interception strategy we're using as well when we decorate our classes. You can intercept methods as well as property accessors by decorating the get or set. Below is a simple example of a virtual interceptor registration.

             public class SpyVirtualAttributes

            {

                [VirtualIntercept(typeof(RecordingHandler))]

                public virtual void InterceptedMethod()

                {

                    Recorder.Records.Add("In Method");

                }

            }

I'm not going to post all of the tests, but I want to give you an idea of the power of this. It's still early in the process and there is some cleanup still going on. But, I encourage you to pick up the source, read it, grok it, give it a try and give feedback.

Conclusion

As you can see, the extensibility model of Unity works in that we can add interception to Unity. So, we can start thinking about moving our cross cutting concerns to these layers should we so choose if Unity is your container of choice. There are plenty of containers out there to choose from, so it's best to give them all a try and pick one based upon features, programming style, and heck, maybe even licensing. I'll be showing some of this stuff off tomorrow at the CMAP Code Camp, so if you'll be at my 1PM session, be prepared. Until next time...

xUnit.net RC3 Just Released

Matthew Podwysocki — Thu, 10 Apr 2008 22:37:38 GMT

Well, Brad Wilson and Jim Newkirk must really be busy lately. After I talked about the release of xUnit.net RC2, just today, Brad announced the release of RC3. As always, you can find the latest bits here. This fixes a number of bugs and adds CruiseControl.NET and ASP.NET MVC Preview 2 support as well in addition to the Resharper 3.1 and TestDriven.NET support. For more information about it, check out Brad's post here. More or less, they are feature complete for version 1.0 and the only that I think really is needed at this point is a decent GUI runner and that's well acknowledged as something they are working on. Visual Studio integration would be nice as well...

For my other posts in this series, check them out here:

If you were in attendance at last night's RockNUG appearance, all tests for my demos were using xUnit.net, so I am actively using it right now and will be for my CMAP Code Camp appearance this weekend. However, I did not show the GUI runner because, well, it's not there yet, and instead, the console runner works just fine, thank you. So, go ahead and pick up the latest bits and give the team feedback!

One last note regarding Brad, he was recently interviewed by Scott Swigart and Sean Campbell over at How Software Is Built and gives some interesting insights in the open source world inside and outside Microsoft and his contributions to it. Very good interview and well worth the time to read.

Unity 1.0 Released into the Wild

Matthew Podwysocki — Mon, 07 Apr 2008 04:40:55 GMT

As Chris Tavares mentioned in his blog, Unity 1.0 has been released a couple of days earlier than the April 7th release date mentioned by Grigori Melnik earlier. Scott Densmore also announced this as well as working on porting the inteception from ObjectBuilder2 which I talked about earlier in some of my Unity and IoC containers posts. Looking forward to that post as we've shared some emails on the subject.

Would You Like To Know More?

For those looking for my posts on the matter, I've covered it quite extensively with the comparison to other IoC containers as well as IoC containers in general:

IoC and Unity - Configuration Changes for the Better
Covers the latest configuration changes to allow for better constructor injection
IoC and Unity - The Basics and Inteception
Covers the basics of an IoC container and inteception techniques
IoC Container, Unity and Breaking Changes Galore
Covers the breaking changes made from the old Unity drop to the new one
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
Managing instances and parameter mapping resolution
IoC and the Unity Application Block Once Again
Setter Injection versus Constructor Injection and PostSharp4Unity
IoC and the Unity Application Block - Going Deeper
Constructor Injection and comparing Unity with Castle Windsor
IoC and the Unity Application Block
Covering ObjectBuilder and Unity Application Block

Anyhow, if interesting in more Unity content, check out David Hayden's Unity IoC and MVC screencast as well as others on the subject here.

Speaking of which, I'm going to be a busy man indeed with my upcoming speaking schedule on IoC containers, not necessarily Unity in particular, but all of them, the background and decoupling your applications. Here is the complete schedule for this month:

RockNUG - April 9th
CMAP Code Camp - April 12th
CMAP Architecture SIG - April 15th

I hope to contribute some at ALT.NET Open Spaces, Seattle as well on a few subjects and DC ALT.NET on April 23rd as well. Should be a great time and feedback is always appreciated.

Relooking at xUnit.net RC2

Matthew Podwysocki — Fri, 04 Apr 2008 22:34:24 GMT

UPDATE: More posts on the subject

xUnit.net RC3 Just Released

Earlier this week, I wrote about the latest release of xUnit.net RC2. Since that time, Brad Wilson and Jim Newkirk released a new version to fix some of the issues with regards to TestDriven.NET integration and ASP.NET MVC integration. You can read more about the issues here. As always you can get the latest bits here.

The Installer

If you browse to the releases page of xUnit.net, you will notice an installer. This installer will help integrate xUnit.net with Resharper 3.1 for Visual Studio 2005 and 2008, TestDriven.NET and ASP.NET MVC. Just click the installer and a screen like below will show. Note that I have Resharper 4.0 nightly builds instead of 3.1, so those features aren't activated just yet, unfortunately.

Since I didn't have anything else but ASP.NET MVC Preview 2 installed, that's all I got enabled. It only takes a few seconds to enable.

ASP.NET MVC

Now that I got the ASP.NET MVC plugin installed for xUnit, I can go ahead and open Visual Studio 2008 and create a new ASP.NET MVC application. When it automatically creates the test project for me, I have the option now of using xUnit.net instead of that lesser one that came in here by default.

Once I do that, it will create some tests of the HomeController and Routes by default as noted below:

But in order for this to work out of the box, there is some work you need to do. Your tests will not compile by default because you need to change the namespace includes on top to include your application's namespace. Not a huge issue mind you, but a little more work than usual. Here's what it will look like:

using MVC_APPLICATION_NAMESPACE.Controllers; // This using directive needs to point to the namespace of your MVC project
using Xunit;
 
namespace PetShopTests.Controllers
{
    public class HomeControllerFacts
    {
        public class Index
        {
            [Fact]
            public void RendersTheIndexView()
            {
                TestableHomeController controller = new TestableHomeController();
 
                controller.Index();
 
                Assert.Equal("Index", controller.RenderView_ViewName);
            }
        }

So, all you need to do is replace the MVC_APPLICATION_NAMESPACE with your own namespace and problem solved! But out of the box, you have some working unit tests and some good guidance on how to get started. If you're curious on how the integration actually works, check out this post here.

GUI Runner

As Brad had stated earlier, there is a simple, yet effective GUI runner for xUnit.net. So far there's not much to it, other than to load an assembly and run all associated tests. To give you an example, I wrote some F# code and now I want to run some tests against it. So, here is the code I used for these simple tests. Yes, you can go ahead and yell at me for doing OO things in a functional language, but it's here to prove a point that you can.

#light

#R @"E:\Tools\xunit-build-1223-samples\Samples\xunit\xunit.dll" 

open System

open System.Collections.Generic

open Xunit

type Stack<'t> = class

  val elements : LinkedList<'t>

  new() = { elements = new LinkedList<'t>() }

  member x.IsEmpty

    with get() = x.elements.Count = 0

  member x.Push element =

    x.elements.AddFirst(element:'t)

  member x.Top

    with get() =

      if x.elements.Count = 0 then

        raise (InvalidOperationException("cannot top an empty stack"))

      x.elements.First.Value

  member x.Pop = 

    let top = x.Top

    x.elements.RemoveFirst()

    top

end

[<Fact>]   

let NoElementsShouldBeEmpty () =

  let stack = new Stack<string>()

  Assert.True(stack.IsEmpty)
 
[<Fact>]

let PushAnElementShouldNotBeEmpty() =

  let stack = new Stack<string>()

  stack.Push("first element")

  Assert.False(stack.IsEmpty)

And now, open the xunit.gui.exe and select your assembly you want to run. I chose my fsharpsamples.dll that I've been working with on my F# samples. Now, let's give these two tests a run to see how they do.

As you can see, not much information is given to me other than the number of passed tests, the time taken and my assembly under test. Not much information, but enough to get started.

Conclusion

As you can see, a bit of progress has been made on xUnit.net and here's hoping the version 1.0 full release is coming soon. As I look at it more and more, I'm definitely starting to like it. I haven't had to create as many extensions as I would have to do with MSTest such as Assert.Throws<T> and so on. So, I encourage you to go ahead and once again, give it a look and give feedback to the team. Until next time...

Covering NUnit 2.4.7

Matthew Podwysocki — Tue, 01 Apr 2008 21:34:37 GMT

It's interesting that a flurry of releases of testing frameworks have been released lately with Gallio, xUnit.net and of course NUnit. Charlie Poole recently announced on a lot of the discussion boards I belong to recently that NUnit 2.4.7 was recently released. You can read all about what's been added here with the release notes.

What's New and Interesting?

What's interesting about this release? Well, NUnit no longer depends on log4net, thus getting rid of some dependency issues with regards to the applications under test. What's also interesting is that addition of the RowTest extension to allow multiple sets of arguments to be given to a test. This is the first one that's ever been incorporated into the core of NUnit.

Static Tests in NUnit?

As Andy Stopford noted in my blog yesterday regarding xUnit.net, Charlie recently checked in code to allow static methods for static methods to be tests as well as Setup and TearDown to be static as well. Jim Newkirk, the man behind NUnit and co-creator of xUnit.net, favors that approach of allowing statics. To me, I don't care as much with regards to Startup and TearDown with statics as most of my statics for testing F# is side effect free programming. As it should be with functional programming. Anyhow, what I'd like to see in NUnit is the support for something that I can do in xUnit.net:

#light

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.core.dll"

#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.framework.dll"

open NUnit.Framework

let rec fib n =

  match n with 

  | 0 | 1 ->  0

  | n -> fib(n-2) + fib(n-1)

  | n when n < 0 -> failwith "Cannot be less than zero"

[<TestFixture>]

let FibOfOneShouldReturnZero() =

  let fibResult = fib(1)

  Assert.AreEqual(fibResult, 0)

If I saw something like this, I'd be a happy man. But until then, I can dream...

Conclusion

Go ahead and pick up your copy today of NUnit. It's been the old standby for many of my projects throughout my career and served me quite well. Next time I'll cover Gallio a little bit as I have neglected it, but it's a huge release.

IoC and Unity - The Basics and InterceptionIoC and Unity - The Basics and Interception

Matthew Podwysocki — Wed, 26 Mar 2008 05:33:03 GMT

I realize it's been a while since my last post on Inversion of Control containers and looking at Unity as one of them. Since that time, Scott Hanselman linked to some of the comparisons that I did for IoC containers here. I'll be the first to admit that the look was a bit naive, but to get you all interested in looking at IoC container and how they can improve your applications. It was suggested here that my posts weren't a complete comparison, although in my previous posts I covered a lot of those topics. Even so, after talking with said individual, I need to cover more ground on the basics and dive deeper into the details.

Where We Are

Before we begin today, let's see what we've already covered in the past:

IoC Container, Unity and Breaking Changes Galore
Covers the breaking changes made from the old Unity drop to the new one
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
Managing instances and parameter mapping resolution
IoC and the Unity Application Block Once Again
Setter Injection versus Constructor Injection and PostSharp4Unity
IoC and the Unity Application Block - Going Deeper
Constructor Injection and comparing Unity with Castle Windsor
IoC and the Unity Application Block
Covering ObjectBuilder and Unity Application Block

So, we have a bit of back history, but I think I dived too far into things without giving some of the back story.

DI Frameworks Galore

As Scott Hanselman noted, there are a number of IoC containers in the .NET Space. Most of these I was already aware of and played with, so I'm only going to list the ones I've played with. Here they are in no particular order:

So, as you can see, there are plenty to choose from. They all serve basic IoC needs and I'll talk about that a little bit more later.

Getting Back to Basics

When we talk about Inversion of Control and dependency inversion principle, we're talking about loosely coupled applications. It follows the Hollywood Principle which is the trite "Don't call use, we'll call you" mantra. In a way it means that those dependencies that you have inside your class, say your Logger and its associated formatter. In the tightly coupled world, you would have a private member of a Logger. Instead, what you would have in the other case is an interface or abstract class that would represent the functionality of that logger, and that instance given to your class. Throw on top of that a container to manage those dependencies to those interfaces and mappings to concrete classes. Also, your container can manage the object lifetimes as well. Ayende shows how easy it is to create a simple container, although it misses an important point about lifetime management.

To put it succinctly, to be a container should satisfy the following requirements:

Configuration - Registering types and mappings through code, XML or script
Lifetime Management - How the lifetime of the objects are managed, singleton, transient, etc
Resolution - Resolve dependencies and instantiate
Extensibility - Be able to add new facilities for additional features (interception, AOP, and so on)

Before we get into any advanced topics, let's get into more detail. James Kovacs wrote in the March 2008 edition of MSDN Magazine called "Loosen Up - Tame Your Software Dependencies For More Flexible Apps". This article is a great start for those trying to understand dependency inversion and dependency injection. James walks through a simple application with tight coupling, and then works to loosen it. Once that is complete, Castle Windsor is introduced and walks through the XML configuration or using Binsor to auto-wire the container.

One of the more key points in this article and it came from Ayende is to have an anti-corruption layer for your IoC container. Yes, that's the same Domain Driven Design term in which we isolate things that don't conform to our given architecture and can translate from one context to another. Let's throw up a simple example of using this. Remember it's just a quick spike of an anti-corruption layer.

namespace UnitySamples
{
    public static class IoC
    {
        private static IDependencyResolver resolver;
 
        public static void Initialize(IDependencyResolver resolver)
        {
            IoC.resolver = resolver;
        }
 
        public static T Resolve<T>()
        {
            return resolver.Resolve<T>();
        }
 
        public static T Resolve<T>(string name)
        {
            return resolver.Resolve<T>(name);
        }
    }
}

So, what we have is an IDependencyResolver given to the singleton IoC container. Like I said, this isn't best practice as I haven't done any checking on whether the resolver was initialized or not. But, what we want is to expose the way of resolving dependencies. Now let's take a look at the IDependencyResolver interface and how that's used.

namespace UnitySamples
{
    public interface IDependencyResolver
    {
        T Resolve<T>(string name);
 
        T Resolve<T>();
    }
}

Not much to this but gives us the ability to resolve our dependencies by type, or by type and name. Pretty simple code here once again. But, if I wanted to suddenly use Unity as the backing store, I'd simply implement it as the following:

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    public class UnityDependencyResolver: IDependencyResolver
    {
        private IUnityContainer container;
 
        public UnityDependencyResolver()
        {
            container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.GetConfigCommand().Configure(container);
        }
 
        public T Resolve<T>()
        {
            return container.Resolve<T>();
        }
 
        public T Resolve<T>(string name)
        {
            return container.Resolve<T>(name);
        }
    }
}

So, all I'd have to do to switch from one container to another is just swap out the IDependencyResolver and I'm finished. But, unfortunately, there are some techniques that are partial to one container or another, so there may be some things I'd lose there. But for most cases, this pattern works and works well at that.

Of course loose coupling, dependency injection and using IoC containers are nice in terms of making unit tests easier, but as you can see, there's a bit more to it than that, including the lifetime management, interception, the flexibility of changing implementations and so on.

Interception and Aspect Oriented Programming

Aspect Oriented Programming (AOP) and basic interception are interesting pieces of some containers. This technique allows us to handle cross-cutting concerns such as logging, transaction management, security and so on at a different level instead of littering our code and domain model with checks everywhere. Instead, we centralize those concerns and have them intercept calls and do their work. Let's get some jargon straight here before we go any further. An aspect is the part that encapsulates the cross-cutting concern such as logging. These aspects can give advice, which is to alter the behavior of a given program. The advice is given at certain join points which is where the aspect advice and the program intersect. A group of these join points are called a pointcut.

Interception is a feature of some of the IoC containers out there. A few come to mind such as Castle Windsor, Spring.NET, LinFu, S2Container, Puzzle.NET and even ObjectBuilder2. These containers provide at least a basic level of interception, meaning that you can intercept calls to methods, analyze the contents of the method call, proceed with the call and even modify the return value. Since most containers support simple interception, I haven't found it more useful than logging or enforcing security on various things. However, it can be extended to support more robust Policy Injection style of programming such as you would find in the Policy Injection Application Block.

Interception in Unity?

Quite a bit has changed with Unity since I last blogged about it in terms of the configuration. You can grab the latest bits here. It would be nice to have changesets and such checked into CodePlex for things like this instead of zip files or MSIs, but oh well. Anyhow, most of the changes revolve around managing lifetimes and handling the parameters for constructor injection. You can read the tests and figure it out.

As I've covered before, right now simple injection in Unity is not supported at the moment. The intention is to have the Policy Injection Application Block fill that role. There is also PostSharp4Unity which can also fit that bill for quick fixes, but I want deep down support for simple interception. Conversations with Brad Wilson led me to ObjectBuilder2 and some spikes that they had with a customer DependencyContainer. So parts of me wondered why that wasn't leveraged at all. Let's take a look at what was implemented in the base of ObjectBuilder2.

Interception in ObjectBuilder2

ObjectBuilder2 was a project by Brad Wilson and Scott Densmore which took the original ObjectBuilder, which was really meant for CAB and not a real container, and made some changes and improvements. Such improvements also came with a few samples of things you can do with it such as a DependencyContainer sample. In here, there are a few interesting pieces. Most of which lie in the interception pieces. Let's take a look at each type below of the ones supported.

        public void InterceptInterface<T>(MethodInfo interfaceMethod,
                                          params IInterceptionHandler[] handlers)
 
        public void InterceptInterface(Type typeToIntercept,
                                       MethodInfo interfaceMethod,
                                       params IInterceptionHandler[] handlers)
 
        public void InterceptRemoting<T>(MethodInfo method,
                                         params IInterceptionHandler[] handlers)
 
        public void InterceptRemoting(Type typeToIntercept,
                                      MethodInfo method,
                                      params IInterceptionHandler[] handlers)
 
        public void InterceptVirtual<T>(MethodInfo method,
                                        params IInterceptionHandler[] handlers)
 
        public void InterceptVirtual(Type typeToIntercept,
                                     MethodInfo method,
                                     params IInterceptionHandler[] handlers)

Now with this, you can see there are three different ways of intercepting, through interfaces, virtual methods or through remoting. We also have the ability to intercept through attributes or through code. Let's walk through a test to see how intercepting through attributes might work.

            [Fact]
            public void InterceptViaAttributes()
            {
                Recorder.Records.Clear();
                DependencyContainer container = new DependencyContainer();
                container.RegisterTypeMapping<ISpy, SpyInterfaceAttributes>();
 
                ISpy obj = container.Get<ISpy>();
                obj.InterceptedMethod();
 
                Assert.Equal(3, Recorder.Records.Count);
                Assert.Equal("Before Method", Recorder.Records[0]);
                Assert.Equal("In Method", Recorder.Records[1]);
                Assert.Equal("After Method", Recorder.Records[2]);
            }

Of course there wouldn't be tests in here without using xUnit.NET of course. Hope to cover that soon enough. Anyhow, as you can see, it's pretty simple to register types in here and then check the expectations through the recorder to see whether the actions happened. To find out what the ISpy and SpyInterfaceAttribtues are actually doing, let's dig through the code.

            public interface ISpy
            {
                void InterceptedMethod();
                void ThrowsException();
            }
 
            internal sealed class SpyInterfaceAttributes : ISpy
            {
                [InterfaceIntercept(typeof(RecordingHandler))]
                public void InterceptedMethod()
                {
                    Recorder.Records.Add("In Method");
                }
 
                public void ThrowsException()
                {
                    throw new Exception();
                }
            }

What this class allows us to do is to register an intercepting interface handler, in this case the RecordingHandler. What we intend to have done is that we record a message once we're in the method. Then our interceptor can put in calls before and after our method call just to prove a point.

namespace ObjectBuilder
{
    public class RecordingHandler : IInterceptionHandler
    {
        readonly string message;
 
        public RecordingHandler()
        {
            message = "";
        }
 
        public RecordingHandler(string message)
        {
            this.message = string.Format(" ({0})", message);
        }
 
        public IMethodReturn Invoke(IMethodInvocation call,
                                    GetNextHandlerDelegate getNext)
        {
            Recorder.Records.Add("Before Method" + message);
            IMethodReturn result = getNext().Invoke(call, getNext);
            Recorder.Records.Add("After Method" + message);
            return result;
        }
    }
}

This IInterceptionHandler interface handles the basic interception tasks of doing some before and after work on the given method. Here it is doing nothing special but recording a message before and after intercepting the method call. I encourage you to dig through this a bit more and understand where it is coming from, because it's good stuff and heck, you might learn some IL emitting as well. It's a shame I didn't see some of this IP get rolled into Unity, but we can hope some of it does.

Interception in Castle Windsor

Like above with ObjectBuilder2, Castle Windsor has a lightweight interception capability as well. I covered this in a previous post, but I'll elaborate on it further. There isn't much on Windsor interception documentation, but you can read about that here. To take advantage of method interception, simply implement the IInterceptor interface which is marked below.

public interface IInterceptor
{
    void Intercept(IInvocation invocation);
}

And then we can implement a simple logger interceptor which goes ahead and logs the before and after information as well as anything else you might want to log that comes from the method signature such as arguments, method name, targets, etc. Here, I'm doing nothing special at all, but play around with the IInvocation interface to find out what you can do.

using Castle.Core.Interceptor;
 
namespace CastleSamples
{
    public class LoggingInterceptor : IInterceptor
    {
        private DebugLogger logger = new DebugLogger();
 
        public void Intercept(IInvocation invocation)
        {
            logger.Log("Before Method");
            invocation.Proceed();
            logger.Log("After Method");
        }
    }
}

Like I said above, I am doing nothing special here other than to show that I can log before and after calls, and I have the option of doing more whether I want to proceed with the method call or not. I can easily register the interceptor either through code, through Binsor or through the XML muck. An post of mine goes through that here.

To me, these lightweight interceptors are nice, but I don't get much value out of them just yet outside of logging and such. Ayende has similar thoughts about the uses of AOP in Windsor here. He also covers doing a Policy Injection Application Block style approach in Windsor as well here.

One off the topics discussed at DC ALT.NET was about using Windsor Interception to implement the Unit of Work pattern to implement undo logic for a WPF application. It was a pretty interesting approach to the issue and I'll definitely have to dig into that a little deeper as well. I'm hoping Phil McMillan starts blogging more anyways... But, obviously there are uses of interception and AOP in the enterprise and I'll get to that in the next post in the series.

Conclusion

As you can see, interception is an interesting topic that needs to be explored a bit more before I'd call this subject done. After all, I haven't touch most other containers, and I definitely want to get into AOP and Spring.NET as it is a topic I'd like to dive a little deeper into as well as AOP in the Enterprise model. Things that make the .NET rramework bend in all sorts of ways is always a worth cause. Anyhow, I hope this dive again into the subject is useful and any feedback is appreciated. Until next time...