What problems does IoC/DI solve
- Makes it easier to adhere to SOLID principles
- Encourages the use of interfaces to allow different implementations
- Loosens coupling, objects don't depend on the implementation of components
- Makes it easier to build up large object graphs made up of small tightly focused components
- Making the same service available everywhere it's needed, eg. a cache.
- Improves testability by allowing the injection of mock components
(My) Issues with IoC/DI
- Moves errors from compile time to run time
- Difficult to determine where something is used or how it got there
Community preference is to use constructor injection, but that doesn't sit well when injecting dependecies dictated by an interface. This seems a natural use of property injection, unfortunately property injection means that you can't guarantee the object won't be partially constructed without checking required properties every time. Some frameworks allow you to specify properties as required, but this doesn't seem to follow an interface-as-contract idiom.
Choosing an IoC/DI container
My requirements for a container beyond the usual are
- .Net 2.0 compatability
- Simplicity
- Allow for code-based configuration
- Support primitive constructor arguments
Simple Injector was the first container I considered, but there were two issues. First was the the minimum .Net 3.5 dependency and second was that the maintainer had decided that doing constructor arguments wasn't going to be supported.
Spring.Net was the second container as the current version support .Net 2.0 (even 1.1 is supported which is rather impressive). However the current version is stuck in the dark ages of XML config-based configuration, yuck! They do note that the next version should support code-based configuration as per the Java version of Spring.
Next steps were to consider older versions of frameworks that were built to support .Net 2.0, this lead me to...
This is not the latest release of StructureMap, that is v2.6.1, but it was the last release to support .Net 2.0. All the config can be done in code and setting up constructor arguments is fairly straight forward.
It is easy to get up and running, with my code to test the requirements looking like
using System.Text;
using StructureMap;
using StructureMap.Configuration.DSL;
namespace StructureMapTest1
{
class Program
{
static void Main(string[] args)
{
var registry = new Registry();
registry.BuildInstancesOf<IInject>().TheDefaultIsConcreteType<Inject>().AsSingletons();
registry.BuildInstancesOf<ITest>().TheDefaultIs(Registry.Instance<ITest>().UsingConcreteType<Test>().WithProperty("i").EqualTo(5)).AsSingletons();
var instanceManager = registry.BuildInstanceManager();
var test = instanceManager.CreateInstance<ITest>();
Console.WriteLine(test.SomeMethod());
Console.WriteLine(test.Id);
var test2 = instanceManager.CreateInstance<ITest>();
test2.I = 10;
Console.WriteLine(test2.SomeMethod());
Console.WriteLine(test2.Id);
}
}
public interface IInject
{
int AnotherMethod(int i);
}
public class Inject : IInject
{
public int AnotherMethod(int i)
{
return i;
}
}
public interface ITest
{
int SomeMethod();
Guid Id { get; }
int I { get; set; }
}
public class Test : ITest
{
private readonly Guid id = Guid.NewGuid();
public Guid Id { get { return id; } }
private int _i;
public int I { get { return _i; } set { _i = value; } }
private readonly IInject _inj;
public Test(IInject inj, int i)
{
_inj = inj;
_i = i;
}
public int SomeMethod()
{
return _inj.AnotherMethod(_i);
}
}
}
Currrent implementation for building/config
Let's start with how the original config worked. When building up the config you could call the methods in any order (except registrations) and the code would fill in the missing gaps. As seen below when you build the IEventPublisher it update the IMessageReceiver which depends on it if it got built first.
private IEventPublisher _eventPublisher;
public IEventPublisher EventPublisher
{
get { return _eventPublisher; }
set
{
if (null == value)
{
throw new ArgumentNullException("EventPublisher");
}
_eventPublisher = value;
if (Synchronous)
{
EventPublisher.Synchronous = true;
}
if (null != MessageReceiver)
{
MessageReceiver.EventPublisher = value;
}
}
}
In the below part you can see the IEventPublisher build itself, here you can see some of it's dependencies, ILogger and IEventStore. If these hadn't been built yet, then they would be null and if they weren't built by run time the exceptions would start being thrown. This is where IoC helps to expose an objects dependencies.
public static class EventPublisherConfigure
{
public static int DefaultBatchSize = 10000;
public static TimeSpan DefaultPublishThreadSleep = TimeSpan.FromSeconds(1);
public static string DefaultSubscriberReceiveMethodName = "Receive";
public static IConfigure EventPublisher(this IConfigure configure) { return configure.EventPublisher(DefaultBatchSize); }
public static IConfigure EventPublisher(this IConfigure configure, int batchSize)
{
var c = configure as Configure;
c.EventPublisher = new EventPublisher()
{
Logger = c.Logger,
EventStore = c.EventStore,
BatchSize = batchSize,
PublishThreadSleep = DefaultPublishThreadSleep
};
return configure;
}
}
Note the size of 23 and 20 lines.
After implementing poor man's DI
Poor Man's DI, is basically implementing each class as if you are using a container, but then don't use one. The dependency graphs are then constructed by hand. Mark Seesmann has a great post on "When to use a DI Container" that illustrates what it looks like.
Below you can see the changes in the config builder, not a huge amount, but we no longer need to add the created IEventPublisher to IMessageReceiver. Advantages are you know at config time if it will work, disadvantage is that now you must build up the config in explicit dependency order.
private IEventPublisher _eventPublisher;
public IEventPublisher EventPublisher
{
get { return _eventPublisher; }
set
{
if (null == value)
{
throw new ArgumentNullException("EventPublisher");
}
_eventPublisher = value;
if (Synchronous)
{
EventPublisher.Synchronous = true;
}
}
}
The changes to the IEventPublisher builder are minimal, dependencies move from being set as properties to being passed into constructors where they are checked that they are not null.
public static class EventPublisherConfigure
{
public static int DefaultBatchSize = 10000;
public static TimeSpan DefaultPublishThreadSleep = TimeSpan.FromSeconds(1);
public static string DefaultSubscriberReceiveMethodName = "Receive";
public static IConfigure EventPublisher(this IConfigure configure) { return configure.EventPublisher(DefaultBatchSize); }
public static IConfigure EventPublisher(this IConfigure configure, int batchSize)
{
var c = configure as Configure;
c.EventPublisher = new EventPublisher(
c.Logger,
c.EventStore,
batchSize,
DefaultPublishThreadSleep,
DefaultSubscriberReceiveMethodName
);
return configure;
}
}
Note the size of 19 and 20 lines, The reduction is all in the config builder itself and can be seen in most of the methods where the need to set other's dependencies are no longer neeed.
What it looks like now
After putting the config builder in the hands of StructureMap there is massive reduction in the amount of code required to create the dependency graph. I'm actually quite impressed at how easy it was. The advantages are that we can go back to building in any order, the disdvantages are that I needed to bring in the concept of an IBuiltConfigure and all the registrations have to wait. But I think it's worth it.
private IEventPublisher _eventPublisher;
public IEventPublisher EventPublisher
{
get { return _eventPublisher; }
}
The builder method is where most of the container setup code is found. But again it is much simpler due to the auto-magic of the container. Here I only really need to set the concrete EventPublisher type and the primitive constructor parameters.
public static class EventPublisherConfigure
{
public static int DefaultBatchSize = 10000;
public static TimeSpan DefaultPublishThreadSleep = TimeSpan.FromSeconds(1);
public static string DefaultSubscriberReceiveMethodName = "Receive";
public static IConfigure EventPublisher(this IConfigure configure) { return configure.EventPublisher(DefaultBatchSize); }
public static IConfigure EventPublisher(this IConfigure configure, int batchSize)
{
configure.Registry
.BuildInstancesOf<IEventPublisher>()
.TheDefaultIs(Registry.Instance<IEventPublisher>()
.UsingConcreteType<EventPublisher>()
.WithProperty("batchSize").EqualTo(batchSize)
.WithProperty("publishThreadSleep").EqualTo(DefaultPublishThreadSleep.Ticks)
.WithProperty("defaultSubscriberReceiveMethodName").EqualTo(DefaultSubscriberReceiveMethodName))
.AsSingletons();
return configure;
}
}
Lines of code have been reduced to 5 and 20, so we have gone from 43, to 39 with poor man's and finally to 25 with the container.
