Evaluating a dependency injection framework

I heard the first time about tdd in the year 2002 when a colleague of mine introduced me to a tool called 'NUnit'. I found tdd very helpful from the beginning and I was always one of them that pushed that paradigm and mindset. I learned like a lot of the other tdd enthusiasts, that 'test first' is good, that 'test isolation' is really necessary, that a 'mocking framework' helps a lot, and that it's all about a good design. On this journey I'm now at a point where I question: could a 'dependency injection framework' help?

That is what I tried to find out today and what this post is about. I wrote a simple application including:

• a wpf client with one window called Window1
• a wcf service called Service with one Methode GetDate() that returns the current date and time
• one assembly testing the wpf-presentation and wcf-service (just unit-tests)

Introducing a DI-Framework

One trying to write tests in such an environment knows that integrating the real wpf- and wcf-environment into the tests is a bad idea. Instead it's better to stub and mock those environments to get easier, more stable, and faster tests. This means we usually want a test-configuration where the most external dependencies (like wpf or wcf) are mocks or stubs. On the other hand we want to have a configuration on a deployed system that utilizes the real dependencies. So it's something about configuration and that's where the DI-frameworks come into play.

I decided to give Jeremy's StructureMap a try because it doesn't look so overloaded like Sprint.NET or Windsor.

Following code shows my wcf-service IService that I include in the presentation-layer as a Service-Gateway (see also ServiceStub-Pattern):

    [ServiceContract]
    public interface IService
    {
        [OperationContract]
        DateTime GetTime();
    }
    /// <summary>
    /// Gateway to intercept for testing
    /// </summary>
    public interface IServiceGateway : IService
    {
        void Close();
    }
    /// <summary>
    /// Real gateway using the wcf generated ServiceClient class
    /// </summary>
    public class ServiceGateway : IServiceGateway
    {
        private readonly ServiceClient _service;

        public ServiceGateway()
        {
            _service = new ServiceClient();
        }

        public void Close()
        {
            _service.Close();
        }

        public DateTime GetTime()
        {
            return _service.GetTime();
        }
    }
    /// <summary>
    /// Stub for testing
    /// </summary>
    public class ServiceGatewayStub : IServiceGateway
    {
        public void Close()
        {
        }

        public DateTime GetTime()
        {
            return new DateTime(2000, 1, 1, 12, 34, 55, 12);
        }
    }

Step 1:
Using the following code to resolve the reference to the external wcf-service

IServiceGateway gateway = ObjectFactory.GetInstance<IServiceGateway>()

and using the following configuration for the tests

<StructureMap>
  <DefaultInstance PluginType="HelloNTPresentation.IServiceGateway,HelloNTPresentation" PluggedType="HelloNTService.ServiceGatewayStub,HelloNTTests"  Scope="Singleton"/>
</StructureMap>

I could wire the code during the tests to the ServiceGatewayStub instead of the real ServiceGateway.

Step 2:
I didn't like that because it meant that we have to setup a configuration for the real (not test) environment like:

<StructureMap>
  <DefaultInstance PluginType="HelloNTPresentation.IServiceGateway,HelloNTPresentation" PluggedType="HelloNTPresentation.ServiceGateway,HelloNTPresentation"  Scope="Singleton"/>
</StructureMap>

After I have had read how to build an IoC container in 15 lines of code I thought that DI can't be so difficult and I tried to build my own DI-framework. I liked very much that I could configure the DI in the code now and eliminate the file-based configuration:

      ObjectFactory.Register<IServiceGateway>(() => new ServiceGatewayStub());
      IServiceGateway gateway = ObjectFactory.Create<IServiceGateway>();

All tests were green and I was happy to start the refactored sample application first time after. But there was big surprise when it crashed. I had forgotten to configure DI for the wcf-service and wpf-service. But where should I put that configuration? Both of them run in some kind of hosted environment and I wasn't able to find a nice place to put that configuration-code. So I realized that it's a little bit harder than I thought to write an own DI-Framework.

Step 3:
Back to StructureMap I found a way to minimize the file-based configuration. The solution was to use the attributes PluginFamily and Pluggable that define default behaviour. In this case the class ServiceGateway is the default implementation of IServiceGateway and there is no need to configure it for the wcf-service and the wpf-client anymore.

    [ServiceContract]
    public interface IService
    {
        [OperationContract]
        DateTime GetTime();
    }
    [PluginFamily("ServiceGateway")]
    public interface IServiceGateway : IService
    {
    }
    [Pluggable("ServiceGateway")]
    public class ServiceGateway : IServiceGateway
    {
    }

Step 4:
Now let's have a look to following the presenter (presenter is what is responsible for the presentation-logic):

    public class Presenter: IDisposable
    {
        readonly IView _view;
        readonly IServiceGateway _service;

        public Presenter(IView view, IServiceGateway service)
        {
            _view = view;
            _service = service;
        }
    }

That presenter shows all internal dependencies on its constructor. This enables us to use constructor injection when writing tests with a Mock-Framework (e.g. TypeMock)

     _serviceGatway = RecorderManager.CreateMockedObject<IServiceGateway>();
     _view = RecorderManager.CreateMockedObject<IView>();
     _presenter = new Presenter(_view, _serviceGatway);

But what's about the others that don't want to bother about providing those dependencies to the constructor? And that's where the DI-framework gets really valueable because it enables us to instantiate concrete classes without providing the needed arguments to the constructor. Following code is from the wpf-client and shows how this is done:

    Presenter presenter = ObjectFactory.FillDependencies<Presenter>();

Just for completeness, I have to mention how I configured IView:

    [PluginFamily("Window1")]
    public interface IView
    {
    }
    [Pluggable("Window1")]
    public partial class Window1 : Window, IView
    {
    }

Summary

• I always used constructor injection but with a DI-framework it gets easier because the client code doesn't need to manage the dependencies anymore.
• I like StructureMap because it looks simple and it works.