Test Driven Development

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.

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.

XUnit.net RC2 Released

Matthew Podwysocki — Tue, 01 Apr 2008 00:31:06 GMT

UPDATE: More posts on the subject

UPDATE: xUnit.NET RC2 New Drop includes ASP.NET MVC support and better GUI runner. Details here.
UPDATE: Added Static Methods mention and F# - Thanks to DevHawk!

I've been a big fan of such testing frameworks as NUnit and MbUnit, but recently I've found myself getting pulled more towards xUnit.net at least to play around with for any of my code samples that I write for this blog and on my own time. I'm not really a fan of MSTest and many I think would agree about its deficiencies. I won't go as far as say Jay Flowers and wear the shirt though...

Another Release?

Recently, Brad Wilson and Jim Newkirk recently announced the release of xUnit.net RC2 on CodePlex. I'd encourage you download the latest bits here. For those wondering what changes happened between RC1 and RC2, Brad has a good writeup on his blog here. What's interesting about this is the removal of the Assert class methods which take a user defined message should it fail. I was never really a fan of those in the first place though.

Another interesting added features was the IUserFixture<T> which allows you to have a startup and teardown for your fixtures in a separate class and therefore reusable, unlike the current way of using no parameter constructors as your startup and the IDisposable.Dispose for your teardown. See the tests in the FixtureExample for details. But here's a snipped version of that code:

    public class DatabaseFixture : IDisposable
    {
        SqlConnection connection;
        int fooUserID;
 
        public DatabaseFixture()
        {
            string connectionString = ConfigurationManager.ConnectionStrings["DatabaseFixture"].ConnectionString;
            connection = new SqlConnection(connectionString);
            connection.Open();
            string sql = @"INSERT INTO Users VALUES ('foo', 'bar'); SELECT SCOPE_IDENTITY();";
 
            using (SqlCommand cmd = new SqlCommand(sql, connection))
                fooUserID = Convert.ToInt32(cmd.ExecuteScalar());
        }
 
        public SqlConnection Connection
        {
            get { return connection; }
        }
 
        public int FooUserID
        {
            get { return fooUserID; }
        }
 
        public void Dispose()
        {
            string sql = @"DELETE FROM Users WHERE ID = @id;";
 
            using (SqlCommand cmd = new SqlCommand(sql, connection))
            {
                cmd.Parameters.AddWithValue("@id", fooUserID);
                cmd.ExecuteNonQuery();
            }
 
            connection.Close();
        }
    }

What the above code allows us to do is to define a class that holds the data from the initialization of the first test, to the cleanup after the last test. Our state is therefore maintained in a reusable manner. As you will note, the startup logic resides in the default no parameter constructor and all teardown logic is in the IDisposable.Dispose method.

    public class FixtureTests : IUseFixture<DatabaseFixture>
    {
        DatabaseFixture database;
 
        public void SetFixture(DatabaseFixture data)
        {
            database = data;
        }
   
        [Fact]
        public void FooUserWasInserted()
        {
            string sql = "SELECT COUNT(*) FROM Users WHERE ID = @id;";
 
            using (SqlCommand cmd = new SqlCommand(sql, database.Connection))
            {
                cmd.Parameters.AddWithValue("@id", database.FooUserID);
                int rowCount = Convert.ToInt32(cmd.ExecuteScalar());
                Assert.Equal(1, rowCount);
            }
        }
    }

Then we can go ahead with our tests, while using the SqlConnection as defined on our DatabaseFixture. After we're done with our test, it goes ahead and calls Dispose on the fixture. I tend to like this approach and it's definitely growing on me.

Why xUnit.net?

For those new to xUnit.net, there are some decent links to help you along. Some of the more interesting ones can be found here:

But, why am I interested in it? Well, let's just say that I think it tackles things in a slightly different manner. I think one of the key pieces that I really like is the Assert.Throws instead of the clumsy ExpectedExceptionAttribute which you must clutter your tests with on the top. I would rather assert that such a thing happened programmatically, so that I may analyze the exception. I can also specify which line I expect during my test will throw the exception, instead of taking on blind faith that my test threw an exception. It may be of the right type, but that may not have been the one you wanted, thus giving a false sense of security.

To use this, just simply use the Assert.Throws<TException>(Assert.ThrowsDelegate) which I've found to be very helpful. Let's look at a quick test of that being used.

    [Fact]
    public void PopEmptyStack()
    {
        Stack<string> stack = new Stack<string>();
        Assert.Throws<InvalidOperationException>(() => stack.Pop());
    }

As you can see, we're pretty explicit about what line will throw the exception, and that's really the key to this scenario. There are a good number of samples provided on the releases page that you should check out. As always with most products that I talk about, I highly recommend reading the tests to really fully understand what's going on underneath the covers. Not only does it help you understand the intent of the program, but you can learn about good coding techniques, design patterns, testing patterns and so on.

Another point that xUnit.net separates itself from the pack is the ability to decorate static methods as facts. This frees you from having to create an instance of your test class in order to call them. Harry Pierson, aka DevHawk, demonstrates its use with regards to F# and testing the parse buffer here. It definitely opened my eyes and a few more avenues as I pursue more F# related work items in the future. Here's just a quick and dirty sample of showing how you can use xUnit.net with F# quite easily, just as Harry's post did.

#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)

If you notice, the FactAttribute is placed on a static method called NoElementsShouldBeEmpty and sure enough it works like a champ through xUnit.net. I like this approach instead of the pomp and circumstance required for creating classes as shown above with my Stack class. Note the use of the empty parans which forces it to be a void method with no values passed either. But if you run it through the xunit.console sure enough it succeeds like a champ.

What are we missing though? Well, I'm in favor of having a standalone GUI Test Runner much like NUnit and MbUnit have. In fact, Brad has started this and you can get these features from the latest commits here. Mind you I haven't gotten it to work just right yet, but it's a work in progress.

Conclusion

There is a lot to like about xUnit.net and takes a lot of lessons learned from the use of NUnit, MbUnit and others and I think they're doing a good job incorporating issues. This project isn't as active as MbUnit and NUnit, but it's definitely one to keep an eye on. Recent releases of NUnit and Gallio Automation Platform will probably be also covered in the short while as well as they have a lot to offer. Until next time...

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...

RockNUG Meeting 3/12/2008 - Refactoring in C#

Matthew Podwysocki — Mon, 10 Mar 2008 23:39:24 GMT

The Rockville .NET User Group (RockNUG) will be holding their next meeting on Wednesday, March 12th, 2008 from 6:30PM-9:00PM. This month, they'll be having a pretty interesting topic on refactoring in C# with Jonathan Cogley. I've had my refactoring and agile boots on lately, so I can definitely relate. I don't know what I would do though without my Resharper 4.0 Nightly Builds... I've had a few issues here and there, but nothing to discourage me from continuing usage.

Anyhow, here are the details:

Location:
Montgomery College, Rockville
Humanities Building - Room 103

Refactoring in C# - Bad code to better code
presented by Jonathan Cogley

What could be more fun on a Wednesday evening than critiquing some bad
code and making it better? :) Come along to learn how to clean code like
the Thycotic team. What do we look for? How do we take small steps to
keep it working? What tips and tricks make it easier? This session
will be code, code and more code (and a few unit tests of course!).

Jonathan Cogley is the founder and CEO of thycotic - a software
development company operating in the Washington DC Metro Area with
offices in Vienna, Virginia. Jonathan has worked for many interesting
companies over the last decade as a software consultant in both the UK
and the USA. His company has released various .NET projects and APIs
including an implementation of Remote Scripting for .NET, a database
platform independent data access layer for ISVs and various tools for
the Test Driven Developer. Test Driven Development (TDD) is the
cornerstone of the thycotic approach to software development and the
company is committed to innovate TDD on the Microsoft .NET platform with
new techniques and tools. Jonathan is also a columnist and editor for
the popular ASP.NET Web site, ASPAlliance. He is an active member in the
developer community and speaks regularly at various .NET User Groups,
conferences and code camps across the US. Jonathan is recognized by
Microsoft as an MVP for C# and has also been invited to join the select
group of the ASPInsiders who have interactions with the product teams at
Microsoft.

The schedule for the event is as follows:

n00b Session	6:30 - 7:00	ASP.NET GridView Part III
Pizza/Announcements	7:00 - 7:30
Featured Presentation	7:30 - 9:00	Jonathan Cogley: Refactoring in C# - Bad code to better code

Hope to see a great crowd there! I'm looking forward to it.

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 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...

Fluency in Fluent Interfaces

Matthew Podwysocki — Fri, 01 Feb 2008 23:47:41 GMT

Scott Hanselman's recent post about the Daily Source Code 14 - Fluent Interface Edition got me to think more on fluent interfaces and a previous post of mine on ObjectMother versus Test Data Builders. Also, it comes to mind in regards to DSLs, both internal and external that has me intrigued. Partially due to my latest involvement with Ruby and F#.

Test Data Builder Example

So, let's revisit that simple example:

public class ClaimBuilder
{
     private DateTime claimDate;
     private Provider provider = ProviderBuilder.StartRecording().Build();
     private Recipient recipient = RecipientBuilder.StartRecording().Build();
     private ClaimLineCollection claimLines = ClaimLinesBuilder.StartRecording.Build();

     public static ClaimBuilder StartRecording()
     {
          return new ClaimBuilder();
     }

     public ClaimBuilder WithClaimDate(DateTime claimDate)
     {
          this.claimDate = claimDate;
          return this;
     }

     public ClaimBuilder WithProvider(Provider provider)
     {
          this.provider = provider;
          return this;
     }

     public ClaimBuilder WithRecipient(Recipient recipient)
     {
          this.recipient = recipient;
          return this;
     }

     public ClaimBuilder WithClaimLines(ClaimLineCollection claimLines)
     {
          this.claimLines = claimLines;
          return this;
     }

     public static implicit operator Claim(ClaimBuilder builder)
     {
          return new Claim(builder.claimDate, builder.provider, builder.recipient, builder.claimLines);
     }
}

As you may note I changed the Build method from the previous post to an implicit operator to save me some coding time when it comes to my builders. This is one of the very very few places where I'd recommend using this operator. Anyhow, then we'd have the calling code to look similar to this for my unit tests.

Claim claim = ClaimBuilder.StartRecording()
     .WithClaimDate(new DateTime(2008, 1, 1))
     .WithProvider(ProviderBuilder.StartRecording()
          .WithName("Robert", "Jones")
          .WithAddress(AddressBuilder.StartRecording()
               .WithStreetAddress("1800 28th St, NW")
               .WithCity("Washington")
               .WithState("DC"))))
     .WithRecipient(RecipientBuilder.StartRecording()
          .WithName(James", "Smith")
          .WithAddress(AddressBuilder.StartRecording()
               .WithStreetAddress("1210 14th St, SE",)
               .WithCity("Washington")
               .WithState("DC"))))
     .WithClaimLines(ClaimLinesBuilder.StartRecording()
          .WithClaim("00308-1")));

This is truly powerful here to make it make sense to the reader instead of the usual black box ObjectMother approach. When building my entity objects for test, this is the main approach I use.

Other Examples

Scott Bellware has introduced the Behavior Driven Development NUnit Extensions which makes heavy use of fluent interfaces. With my deeper dive into BDD, this has been very helpful. Dave Laribee also has me on the kick as well, so lots of thanks to them for pointing me in the right direction, although some may disagree with their directions. But that's for another time and another post.

Jeremy Miller also has fluent interfaces on his StructureMap IOC container project.   Some new parts with registration will be coming up with his new release of version 2.5 as noted here.

Of course I can keep rattling on with others like NHibernate and the ICriteria, Castle Windsor's fluent registration interfaces and so on. The list goes on! Very cool stuff coming out lately... Until next time!