Free Tools

Unity Community Contributions and Interception

Matthew Podwysocki — Sat, 12 Apr 2008 00: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 23: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 05: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 23: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 22: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 06: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...

IoC Container, Unity and Breaking Changes Galore

Matthew Podwysocki — Fri, 07 Mar 2008 08:13:25 GMT

Update: IoC and Unity - The Basics and Interception

As Grigori Melnik noted on my blog previously as well as his own, there was a brand new drop of the Unity Application Block as of March 4th. This by far was a huge update with a lot of breaking changes. That teaches me to use a CTP of any product and blog about it actively as it compares to other Inversion of Control (IoC) containers. Glad I didn't do a lot on ASP.NET MVC just yet but I have a few good projects going on the side with that now.

Where I've Been Before

As noted here before, I've been spending some time actively comparing the Unity Application Block to other IoC containers and what each offers. Let's get caught up to my previous posts:

I'm probably going to change the code on each one just so that you all don't get angry about code from me not working, so stay tuned, it will get done. But, keep in mind, it is still CTP, and I'd rather concentrate on the concepts as well.

What's Changed

As you may notice if you did any of the code snippets I published, they sure as heck don't build anymore. So, let's enumerate the changes made so far:

UnityContainer method Register<TFrom, TTo>() becomes RegisterType<TFrom, TTo>()
UnityContainer method Get<T>() becomes Resolve<T>
UnityContainer method SetSingleton<T> removed
UnityContainer method RegisterType<TFrom, TTo> accepts a LifetimeManager to create Singletons
Added ContainerControlledLifetimeManager and ExternallyControlledLifetimeManager
Removed DependencyAttribute NotPresentBehavior property and enum
Added UnityContainer CreateChildContainer method to create child sandboxes
Reversed the parameters for UnityContainer method RegisterInstance<T>(value, key) to RegisterInstance<T>(key, value)

As you can see, some of these changes can be seen as quite annoying especially if I were to have a method such as the following and I can't find the error until I sit and read the code through and through:

Old:

IUnityContainer container = new UnityContainer();
container
    .RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager())
    .RegisterInstance<string>("administrator@example.com", "defaultFromAddress");

And sure enough, it blew up due to the fact that it seemed just fine because it was RegisterInstance<string>(string, string) and instead I had to change it to this to get it to work.

New:

IUnityContainer container = new UnityContainer();
container
    .RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager())
    .RegisterInstance<string>("defaultFromAddress", "administrator@example.com");

Nothing from what I can tell changed in the XML configuration, but I prefer to register my types by code instead. The only thing I really like to switch out from time to time is a Logger of some sort.

Another interesting aspect is the concept of child containers in their own sandbox as it were. Take for example, we have two loggers, a DebugLogger and a ConsoleLogger. We have the ability to have these registered in two different child containers all managed by the parent. Let's walk through a simple example of this.

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            UnityContainer parentContainer = new UnityContainer();
            IUnityContainer childContainer1 = parentContainer.CreateChildContainer();
            childContainer1.RegisterType<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager());
            IUnityContainer childContainer2 = parentContainer.CreateChildContainer();
            childContainer2.RegisterType<ILogger, DebugLogger>(new ContainerControlledLifetimeManager());
 
            ILogger logger1 = childContainer1.Resolve<ILogger>();
            ILogger logger2 = childContainer2.Resolve<ILogger>();
            logger1.Log("Foo");
            logger2.Log("Bar");
        }
    }
}

What seemed a little annoying to me is that CreateChildContainer is not available from the IUnityContainer, and instead only from the UnityContainer concrete class instead. But as you can see, I create two loggers each in their own sandbox, one a DebugLogger and one the ConsoleLogger.

What I'd Like To See

As I've said before, I'm not entirely sold on the Unity Application Block as I like a lot of the other ones in the Open Source Community as well including Castle Windsor, StructureMap and Spring.NET. It's heartening that they are taking a lot of advice from the community to heart and having quick drops for public approval. When people are evaluating IoC containers, it's critical that you have a list of essential features that the container must support. You may also note that your needs for this may change from project to project, so don't assume that if it worked well here that it will suit your needs on all projects. Due diligence must be done in tool and framework analysis to get the right tool for the right job.

With that in mind, I have a few things that I'm looking for right now in an IoC container. Some of these requirements are as follows:

Must be lightweight (No heavy XML lifting required)
Must support interception and AOP with runtime weaving (compile time might be nice)
Should be opinionated so that I don't need to mark my dependencies in my constructor, instead match by name
When I ask for a logger, give me one and I don't care which
Support easy object registration through fluent interfaces

But like I said, it evolves quickly and changes from project to project. What's your list and why?

Further Thoughts About IoC

Nick Malik recently blogged about IoC container and their overuse in a two part blog series here and here. In his first post, he tends to think that people are religious about the use of IoC containers and not just the Dependency Injection pattern in particular. In the second post, he covers that the use of the IoC container is only as good as the team that understands its impact and applicability. Most tools have their limits and uses. Mocking containers have the same issue. Once you start mocking for parts of your tests, then there is a good chance for abuse and overuse as well. I see his point, but I disagree that many teams are not up for IoC containers and general good design practices of Dependency Injection.

Wrapping It Up

Next time, I'd like to get into the extensibility model of each container in terms registering extensions and so on. In the mean time, I hope you go and evaluate your needs for an IoC container, even whether you need one or not. Until next time...

IoC Containers, Unity and ObjectBuilder2 - The Saga Continues

Matthew Podwysocki — Tue, 04 Mar 2008 08:15:34 GMT

Update: Fixed code changed from CTP and More in the series:

IoC Container, Unity and Breaking Changes Galore

I just wanted to revisit the whole Unity Application Block just once more to look at a few more things including handling parameters, instances and so on. If you hadn't seen, there was another source drop of Unity as of 2/26, so if you haven't picked it up, feel free to do so here.

So, we're going to continue our look at DI and IoC containers as they pertain to different needs. I'm not going to be a gloryhound about any particular IoC container, instead, just lay out how each one does its job and you decide whether you want to use it or not. And that's the main point I want to emphasize here that each tool has its purpose and its needs that it solves and it's up to you do decide whether it meets your needs and programming style.

Where We Are

Anyhow, I covered the Unity Application Block in a few other posts lately as it relates to other Inversion of Control (IoC) containers. I covered the basics with the Unity Application Block, StructureMap and Castle Windsor. Check them out before we go any further today:

Now that we're caught up to where we have been, let's dive into the other subjects in the same area of concern. Unity has an interesting way of dealing with several issues that I want to cover in respect to other IoC containers. And they are:

Managing Instances and Parameters
Method Call Injection
Unity Application Block versus ObjectBuilder2

Managing Instances or Parameters?

The previous two times, we talked about constructor injection and setter injection, but not really about managing simple types and mapping them to our constructors. It's usually a simple thing, but yet, we have three different ways of attacking the very same problem. That's the very point of these blog posts to point that out and it's once again echoed here.

To set up this scenario, we have a simple SmtpEmailService which is used to send emails to users in our system. It's a pretty naive sample, yet will illustrate some simple constructor injection with both simple and complex types. We're going to inject a default from address and a logger into our service and go from there.

We'll start with our Unity sample of how we are going to map those simple and complex types to the constructor. Let's start off with the basic logger interface and implementation. I'll only post this part once as it will apply the same to each of the samples.

namespace UnitySamples
{
    public interface ILogger
    {
        void Log(string message);
    }
}

And once again, we have our concrete implementation with the console logger.

using System;
 
namespace UnitySamples
{
    public class ConsoleLogger : ILogger
    {
        public void Log(string message)
        {
            Console.WriteLine(message);
        }
    }
}

Now, let's tie it together with the point of today's post, the SmtpEmailService. We will have two parameters in this scenario, the default email address, and the logger used for logging.

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    public class SmtpEmailService : IEmailService
    {
        private readonly string defaultFromAddress;
        private readonly ILogger logger;
 
        public SmtpEmailService([Dependency("defaultFromAddress")] string defaultFromAddress, ILogger logger)
        {
            this.defaultFromAddress = defaultFromAddress;
            this.logger = logger;
        }
 
        public void SendEmail(string to, string subject, string body)
        {
            // Send email
            logger.Log(string.Format("Sending email from {0} to {1} with the subject {2} and body {3}", defaultFromAddress, to, subject, body));
        }
    }
}

As you may note, I'm using the DependencyAttribute to decorate the parameter defaultFromAddress. This correlates to the key specified in the config file or when you register an instance, and I'll show you that later.
Let's take a look at the program.cs to use the XML config file to wire up our instances.

using System.Configuration;
 
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.GetConfigCommand().Configure(container);
            SmtpEmailService service = container.Resolve<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

The above code is pretty standard as we've used before, so real surprises here. So, let's take a look at the XML configuration necessary to make this work:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="unity"
                type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
                  Microsoft.Practices.Unity.Configuration" />
    </configSections>
    <unity>
        <containers>
            <container>
                <types>
                    <type type="UnitySamples.ILogger,UnitySamples"
                          mapTo="UnitySamples.ConsoleLogger,UnitySamples"
                          lifetime="Singleton"/>
                </types>
                <instances>
                    <add name="defaultFromAddress" type="System.String" value="administrator@example.com" />
                </instances>
            </container>
        </containers>
    </unity>
</configuration>

What I did is that I utilized the instances node and then add an instance called defaultFromAddress. This node is only used to initialize simple types such as strings, DateTimes, System.Doubles, System.Int32 and so on. Then I can set the value as well. So, if I want to initialize complex types in the types node and the simple types in the instances node.

But, we can also register things through the regular programmatic interfaces as well such as this:

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            container
                .Register<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager())
                .RegisterInstance<string>("administrator@example.com", "defaultFromAddress");
            SmtpEmailService service = container.Resolve<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

As you note, I used the fluent interfaces approach to register the ConsoleLogger as well as the instance of type string which had my value and the key I wanted to use. The first value I use is the value, and the second is the key I want to use to correlate to my DependencyAttribute.

Now, let's look at the StructureMap instance using the same approach. The only pieces I intend to show are just the pieces I changed. So, let's take a look at the SmtpEmailService once again.

namespace StructureMapSamples
{
    public class SmtpEmailService : IEmailService
    {
        private readonly string defaultFromAddress;
        private readonly ILogger logger;
 
        public SmtpEmailService(string defaultFromAddress, ILogger logger)
        {
            this.defaultFromAddress = defaultFromAddress;
            this.logger = logger;
        }
 
        public void SendEmail(string to, string subject, string body)
        {
            // Send email
            logger.Log(string.Format("Sending email from {0} to {1} with the subject {2} and body {3}", defaultFromAddress, to, subject, body));
        }
    }
}

As you may note from above, I had no need for the dependency attribute or anything like that. I haven't bothered to put the PluginAttributes or anything like that either as I want to do XML config way. So, let's next look at the program.cs which does the simple email wireup.

using StructureMap;
 
namespace StructureMapSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            SmtpEmailService service = ObjectFactory.GetInstance<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

And then we wire things up with our StructureMap.config file. Note that we set up things through an Instance node and then set the constructor injection parameters through property nodes.

<?xml version="1.0" encoding="utf-8" ?>
<StructureMap>
    <Aseembly Name="StructureMapSamples"/>
  <PluginFamily Type="StructureMapSamples.ILogger" Assembly="StructureMapSamples" DefaultKey="Console" Scope="Singleton">
    <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.ConsoleLogger" ConcreteKey="Console" />
    </PluginFamily>
  <PluginFamily Type="StructureMapSamples.SmtpEmailService" Assembly="StructureMapSamples" DefaultKey="EmailService">
      <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.SmtpEmailService" ConcreteKey="SmtpEmailService" />
      <Instance Key="EmailService" Type="SmtpEmailService">
          <Property Name="defaultFromAddress" Value="administrator@example.com" />
          <Property Name="logger" Key="Console" />
      </Instance>
  </PluginFamily>
</StructureMap>

I tidied up the XML configuration a bit after taking Jeremy Miller's advice and trying to collapse it down as much as possible. I'm sure I still don't have it to the smallest amount possible, but at least it's legible. Now, let's go ahead and use the DSL for configuration instead of the simple program.cs we have above.

using StructureMap;
using StructureMap.Configuration.DSL;
 
namespace StructureMapSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            StructureMapConfiguration.UseDefaultStructureMapConfigFile = false;
            StructureMapConfiguration.BuildInstancesOf<ILogger>()
                .TheDefaultIsConcreteType<ConsoleLogger>().AsSingletons();
            StructureMapConfiguration.BuildInstancesOf<SmtpEmailService>().TheDefaultIs(
                Registry.Instance<SmtpEmailService>().UsingConcreteType<SmtpEmailService>()
                    .WithProperty("defaultFromAddress").EqualTo("administrator@example.com"));
            SmtpEmailService service = ObjectFactory.GetInstance<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

As you can see from above, it's a pretty simple thing to use the more fluent interfaces here as well to register what we're interested in. We're making sure it doesn't use the default StructureMap.config file and then build up an instance of an ILogger as a singleton, and then use the injection on the SmtpService to set the defaultFromAddress. The ILogger it should automatically figure out itself.

Now, let's finally move onto Castle Windsor. I must admit, I'm most familiar with Castle Windsor, but I'm learning something new about each of these every day, which is a good thing. So, the only classes I really need to show is the program.cs and the configuration file to show what has changed. So, let's start with the program.cs file:

using Castle.Windsor;
using Castle.Windsor.Configuration.Interpreters;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer(new XmlInterpreter());
            SmtpEmailService service = container.Resolve<SmtpEmailService>();
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

This is a pretty simple example of using the XmlInterpreter which reads the XML configuration file to read what we want to set. And then our XML configuration file should look something like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="castle"
            type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
    </configSections>
    <castle>
        <components>
            <component id="emailservice.smtp"
                type="CastleSamples.SmtpEmailService, CastleSamples">
            <parameters>
                <defaultFromAddress>administrator@example.com</defaultFromAddress>
            </parameters>
        </component>
        <component id="logger.console"
                       service="CastleSamples.ILogger, CastleSamples"
                       type="CastleSamples.ConsoleLogger, CastleSamples"
                       lifestyle="singleton" />
        </components>
    </castle>
</configuration>

I could have also specified the logger as well as a parameter by noting it inside the parameters node such as this:
<logger>${logger.console}</logger> to specify that it uses the ConsoleLogger, but it's not really necessary to do so.

Instead, let's use the XML free way of configuration just to prove a point we can do it both ways:

using System.Collections.Generic;
using Castle.Core;
using Castle.Windsor;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer();
            container.AddComponentWithLifestyle("logger.console", typeof (ILogger), typeof (ConsoleLogger),
                                                LifestyleType.Singleton);
            Dictionary<string, object> properties = new Dictionary<string, object>();
            properties.Add("defaultFromAddress", "administrator@example.com");
            container.AddComponent("emailservice.smtp", typeof (SmtpEmailService));
 
            SmtpEmailService service = container.Resolve<SmtpEmailService>(properties);
            service.SendEmail("me@example.com", "Test email", "This is a test email");
        }
    }
}

So, as you can see, it's pretty simple to set the parameters on our SmtpEmailService through the use of a Dictionary<TKey, TValue> generic collection. The rest is just plain simple.

Method Call Injection

The Unity Application Block introduces another concept called method call injection. Yes, that's right, instead of using constructor injection or setter injection, you can use method call injection. The basic premise is that you can inject any method as you would for a constructor or setter.

When would you use this though? If you read the documentation, it lays out the explanation as follows:

You want to instantiate dependent objects automatically when your instantiate the parent object
You want a simple approach that makes it easy to see in the code what the dependencies are for each class
The parent object requires a large number of constructors that forward to each other, making debugging and maintenance difficult
The parent object constructors require a large number of parameters, especially if they are of similar types and the only way to identify them is by position
You want to hide the dependent objects by not exposing them as properties
You want to control which objects are injected by editing the code of the dependent object instead of the parent object or application

By default unless any of this matches your criteria, you should just go ahead and use constructor injection. But, let's walk through a small sample of using method injection:

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    public class SmtpEmailService : IEmailService
    {
        private string defaultFromAddress;
        private ILogger logger;
 
        [InjectionMethod]
        public void Initialize([Dependency("defaultFromAddress")] string defaultFromAddress, ILogger logger)
        {
            this.defaultFromAddress = defaultFromAddress;
            this.logger = logger;
        }
 
        public void SendEmail(string to, string subject, string body)
        {
            // Send email
            logger.Log(string.Format("Sending email from {0} to {1} with the subject {2} and body {3}", defaultFromAddress, to, subject, body));
        }
    }
}

The rest of our program shouldn't have to change with this scenario. But, as you will note from above, we decorated our Initialize method with an InjectionMethodAttribute which makes it realize that instead of constructor injection, use this instead. And it works like a charm. I haven't run into a scenario yet where I would find it useful, but I find it interesting. If anyone does have a scenario that they've run into, please let me know.

Unity == ObjectBuilder2?

As you may have noticed, if you had downloaded the Unity Application Block, you'll notice that it is built upon ObjectBuilder2, but you may also notice that it hides a lot of functionality that it provides. When you are marking your classes with DependencyAttribute and other things, you will notice that there are two of them, one in Unity and one in ObjectBuilder2, so this got me curious on what else I was missing out on.

If you've played around with Enterprise Library in the past, you have probably dealt with ObjectBuilder. It was not the most delightful piece of code I've ever had to deal with and not very intuitive. Brad Wilson and Scott Densmore took it upon themselves to rewrite this into a much more usable piece of code. You can download the original and unencumbered ObjectBuilder2 from CodePlex here.

Take a look at the CodePlex DependencyInjection project and its associated tests in Tests.CodePlex.DependencyInjection for a good idea on how well Brad and Scott did with their DI framework. The best way to learn about any framework is to read the tests or specs (BDD style of course). Let's look at two ways of doing code interception using the DI framework with using code and using attributes.

            [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]);
            }
 
            [Fact]
            public void InterceptViaCode()
            {
                Recorder.Records.Clear();
                DependencyContainer container = new DependencyContainer();
                container.RegisterTypeMapping<ISpy, SpyInterface>();
                container.InterceptInterface<SpyInterface>(typeof(ISpy).GetMethod("InterceptedMethod"),
                                                           new RecordingHandler());
 
                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]);
            }

Ok, so you may note that we registered this with an ISpy interface. Then we have two implementations, one with code and one using attributes. Let's now inspect that code.

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

As you may note, we have two methods that we're interested in, the InterceptedMethod and the ThrowsException method. Then we can test through a Recorder that in fact the code was hit. xUnit.net is used quite frequently throughout the code as it is a project also by Brad and Jim Newkirk. Overall, I'm very impressed with this code and I wish it had made more of an impact.

Chris Tavares and others from the Unity team have taken it upon themselves to redo a lot of the guts of ObjectBuilder2 as they continue to extend Unity. For AOP, the plan is to include the Policy Injection Block into the solution, whereas ObjectBuilder2 already had this piece of functionality and does it quite well. Some of it seems to be right now a little less featured than ObjectBuilder2 at this point, but that can change. I have hopes for Unity, but ObjectBuilder2 did a lot of these things that it claims to do, just a little bit better.

Wrapping it Up

Here wraps up another installment of looking at IoC containers and the various frameworks associated with it. I hope that it whets your appetite to not only understand these containers, but see how they work deep down and see which matches your programming style. Get to know your tools just a little bit better and find out what good quality code can be. I hope you can take this to heart and see what works for you.

IoC and the Unity Application Block Once Again

Matthew Podwysocki — Wed, 27 Feb 2008 00:31:34 GMT

Update: Fixed code changed from CTP and More in the series:

After the reaction of my last post of talking about IoC and the Unity Application Block, I thought I'd include a few more samples of using Unity and how they compare with other IoC containers. I realized after my first one, that I didn't give any love to StructureMap and I'm going to fix that for a brief sample as well. I realize there are plenty of IoC containers out there including Spring, but quite frankly I've found it heavier than most, so I'm going to stick with Unity, Castle Windsor and StructureMap for this example.

Before I continue, check out David Hayden's screencast of IoC with ASP.NET MVC for some more interesting ideas regarding IoC and Unity.

Setter Injection versus Constructor Injection

I've been down the road of constructor injection versus setter injection. My opinion is that you try to inject the most you can through your constructor such as in a Model View Presenter, injecting the View and the Service Layer. Now, you may have cross-cutting concerns such as logging that you may want to swap out, but putting it in the constructor can just get ugly and you can set a default logger in your class anyways such as a NullLogger. Martin Fowler, as always, covers this topic here and it's quite interesting as it is an open debate.

The other option I've done down this road was to create an IContext interface which is injected through the constructor that has some of the cross-cutting concerns wrapped up into it, but for now, let's just walk through a sample of having setter injection as well.

Get Down to Details

Now that we got all the other stuff out of the way, let's go ahead and set up some basic examples in Unity, Castle Windsor and StructureMap doing setter injection. I'll basically take the code from last time and apply it here as well. So, let's start out with the Unity Application Block Sample:

namespace UnitySamples
{
    public interface ILogger
    {
        void Log(string message);
    }
}

And we have two implementations, the NullLogger (the default) and the ConsoleLogger (the override). Let's go through each of those.

namespace UnitySamples
{
    public class NullLogger : ILogger
    {
        public void Log(string message)
        {
            // Do nothing
        }
    }
}

using System;
 
namespace UnitySamples
{
    public class ConsoleLogger : ILogger
    {
        public void Log(string message)
        {
            Console.WriteLine(message);
        }
    }
}

Now that I have these two implementations, I won't bother repeating these for the others unless they specifically change, which they shouldn't. Now, to my implementation details of my CustomerTasks object.

using Microsoft.Practices.Unity;
 
namespace UnitySamples
{
    public class CustomerTasks
    {
        private ILogger logger = new NullLogger();
 
        [Dependency]
        public ILogger Logger
        {
            get { return logger; }
            set { logger = value; }
        }
 
        public void SaveCustomer()
        {
            Logger.Log("Saved customer");
        }
    }
}

As you may note, I set the default implementation of my logger to a NullLogger because by default, I don't care about logging, so it's about the same as a NoOp. But, if I want to change that, I can through my setter injection. This goes for any cross-cutting concern. I also marked my Logger property with the DependencyAttribute which basically says that give me the ILogger instance registered when you go through the container to create it. This of course requires class modification, so it's not a simple rip and replace as it was with constructor injection. So, now let's look at the implementation of our configuration, much as before.

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
 
namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.GetConfigCommand().Configure(container);
            CustomerTasks tasks1 = container.Get<CustomerTasks>();
            CustomerTasks tasks2 = container.Get<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();   
        }
    }
}

And the configuration file will look much like before as:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="unity"
             type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
                   Microsoft.Practices.Unity.Configuration" />
  </configSections>
  <unity>
    <containers>
      <container>
        <types>
          <type type="UnitySamples.ILogger,UnitySamples"
                mapTo="UnitySamples.ConsoleLogger,UnitySamples" 
                lifetime="Singleton"/>
        </types>
      </container>
    </containers>
  </unity>
</configuration>

Now, let's do the same thing with Castle Windsor. Most of the code will be the same from our Unity sample as I can't imagine that much will change except that I don't need to register the DependencyAttribute on the CustomerTasks object. Let's first look at the changed CustomerTasks object.

namespace CastleSamples
{
    public class CustomerTasks
    {
        private ILogger logger = new NullLogger();
 
        public ILogger Logger
        {
            get { return logger; }
            set { logger = value; }
        }
 
        public void SaveCustomer()
        {
            Logger.Log("Saved customer");
        }
    }
}

Now, let's look at the program.cs file to see how really nothing changed at all from our perspective:

using Castle.Windsor;
using Castle.Windsor.Configuration.Interpreters;
 
namespace CastleSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            WindsorContainer container = new WindsorContainer(new XmlInterpreter());
            CustomerTasks tasks1 = container.Resolve<CustomerTasks>();
            CustomerTasks tasks2 = container.Resolve<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();
        }
    }
}

And then our config file looks like this:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section name="castle"
        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
  </configSections>
  <castle>
    <components>
      <component id="customertasks" type="CastleSamples.CustomerTasks, CastleSamples" lifestyle="transient" />
      <component id="logger.console" service="CastleSamples.ILogger, CastleSamples" type="CastleSamples.ConsoleLogger, CastleSamples" lifestyle="singleton" />
    </components>
  </castle>
</configuration>

So, in reality, nothing changed from our constructor injection versus our setter injection implementation for Castle Windsor. That to me is pretty cool... But, now, let's move our attention to StructureMap. Let's walk through only the code that has changed. I'm only going to use the one with the StructureMap.config file and not the fluent interfaces just yet. I know more of the config file and not enough of the interfaces to be effective. Let's go through what really changed. In reality, everything is the same from the Castle Windsor implementation and the StructureMap one except for the Program.cs and the StructureMap.config file, so let's look at the Program.cs first.

using StructureMap;
 
namespace StructureMapSamples
{
    class Program
    {
        static void Main(string[] args)
        {
            CustomerTasks tasks1 = ObjectFactory.GetInstance<CustomerTasks>();
            CustomerTasks tasks2 = ObjectFactory.GetInstance<CustomerTasks>();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();   
        }
    }
}

And to make sure our object is a singleton, let's make our StructureMap.config file and walk through the details:

<?xml version="1.0" encoding="utf-8" ?>
<StructureMap>
  <PluginFamily Type="StructureMapSamples.ILogger" Assembly="StructureMapSamples" DefaultKey="Console">
    <Interceptors>
      <Interceptor Type="Singleton" />
    </Interceptors>
    <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.ConsoleLogger" ConcreteKey="Console" />
    </PluginFamily>
  <PluginFamily Type="StructureMapSamples.CustomerTasks" Assembly="StructureMapSamples" DefaultKey="CustomerTasks">
    <Plugin Assembly="StructureMapSamples" Type="StructureMapSamples.CustomerTasks" ConcreteKey="CustomerTasks">
      <Setter Name="Logger" Key="Console" />
    </Plugin>
  </PluginFamily>
</StructureMap>

If you're familiar with StructureMap, the config file should make sense to you as I'm creating an ILogger with the default implementation being the ConsoleLogger and then we make sure it is a singleton through the use of an interceptor. Then we also do a setter injection through our plugin of the CustomerTasks with setting the Logger property to the key of Console. Pretty simple and straightforward.

So, as you can see, they are very similar in nature, but attack the problem in different ways. That's the beauty of it all, just determine your needs and your programming style and then the pick of your IoC container should come into line with that. These are pretty simple and naive samples, but I just want to whet your appetite to open your mind and look for yourself at these containers for yourself.

AOP with PostSharp and Unity?

Gael Fraiteur recently posted on the altdotnet list about the new release of PostSharp. Gael blogged about that here. A couple of things intrigued me about it, including the license change to LGPL for the runtime and GPL for the code. This requires a commercial license should you want to redistribute it with your application. But, I'll leave that up to him and the lawyers to figure out.

But, let's get back to Unity for just a second. Gael recently announced on the Unity Application Block discussion list about including an extension to support PostSharp which you can find here. You can find the code in particular to do this, plus the Stoplight sample converted at GoogleCode here under PostSharp4Unity. Get your favorite SVN client and pull it down.

So, let's take my basic example from above and try to get it using the default constructors instead of the approach of calling the container to get ourselves an instance. A good approach is to keep the container out of your way and produce cleaner code. A downside of using IoC containers is that they can litter up your code. PostSharp4Unity allows us to create an extension for Unity and use our default constructors.

First, let's create a Unity container provider so that we can initialize our container programmatically. Create a UnityContainerProvider in your project that inherits from the IUnityContainerProvider. That code should look like this:

using Microsoft.Practices.Unity;
using PostSharp4Unity;
using UnitySamples;
 
namespace UnitySamples
{
    public sealed class UnityContainerProvider : IUnityContainerProvider
    {
        private readonly IUnityContainer container;
 
        public UnityContainerProvider()
        {
            this.container = new UnityContainer()
                .Register<ILogger, ConsoleLogger>(new ContainerControlledLifetimeManager());
        }
 
        public IUnityContainer CurrentContainer
        {
            get { return this.container; }
        }
    }
}

Now we also have to mark our assemblyinfo.cs with our default UnityProviderContainer, so open up your assemblyinfo.cs and put this info in there:

using PostSharp4Unity;
using UnitySamples;
 
[assembly: DefaultUnityContainerProvider(typeof(UnityContainerProvider))]

Ok, done and now we have to mark our class that we want to mark our configurable objects that we want to control with PostSharp. So, open CustomerTasks and modify it to this:

using Microsoft.Practices.Unity;
using PostSharp4Unity;
 
namespace UnitySamples
{
    [Configurable]
    public class CustomerTasks
    {
        private ILogger logger = new NullLogger();
 
        [Dependency]
        public ILogger Logger
        {
            get { return logger; }
            set { logger = value; }
        }
 
        public void SaveCustomer()
        {
            Logger.Log("Saved customer");
        }
    }
}

So, then our program.cs can look like this now:

namespace UnitySamples
{
    class Program
    {
        static void Main(string[] args)
        {
            CustomerTasks tasks1 = new CustomerTasks();
            CustomerTasks tasks2 = new CustomerTasks();
            tasks1.SaveCustomer();
            tasks2.SaveCustomer();   
        }
    }
}

But, in order for PostSharp to do its magic, we need to make sure it's part of our compilation targets in our .csproj file. So, I hand munged mine and got it to work like this:

</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(PostSharpDirectory)PostSharp.targets" Condition=" Exists('$(PostSharpDirectory)PostSharp.targets') " />
</Project>

Then I'm able to get the magic of PostSharp to do its work. Pretty slick!

Wrapping It Up

So, I hopefully whetted your appetite for these IoC containers for you to go and do a comparison on your own. Each container has a different way of configuring itself and each solves a different problem set. It's up to you to decide which one to use. Along the way you can have a pretty cool journey though in learning deciding what works for you and what doesn't. Until next time, and hopefully an F# related post...

DC ALT.NET Wrapup and CI Factory

Matthew Podwysocki — Thu, 21 Feb 2008 15:57:05 GMT

Well, due to the weather beyond our control, the crowd was a bit smaller than expected at the February meeting of DC ALT.NET. It seems people panic in the Washington DC area if there is even a hint of moisture in the air or a snow flake hits the ground. It was a smaller crowd, yet passionate and I'd rather have that then a big crowd that wasn't involved at all. We had such people as Craig Andera, Jay Flowers, Kevin Hegg among others who attended. But the topics were great talking about functional programming, with Craig and Lisp and me with F#, continuous integration, the complexity of .NET and what's coming down the line, Domain Driven Design, and managing complexity in projects. Not once did a laptop nor PowerPoint show its head, instead just passionate people talking about technology and ways of thinking.

I want to thank the people at Stelligent and Jay Flowers for making this happen. It couldn't have been better timing as he just released version 1.0.1 of CI Factory yesterday. If you aren't aware of this product, I've blogged about it in the past here. What it does is it creates an out of the box CI environment which is really important to have in an agile environment. Even teams as small as one person can benefit greatly from continuous integration.

Tools supported by CI Factory include:

Jay and Scott Hanselman did an episode on DNRTV about CI Factory here. Of course Scott was being a little snarky for Jay's spelling, but oh well. So, go ahead and give it a try. I've found it very useful and pretty easy to use even for some of the smaller side projects I've done.