Dependency injection is about components…

…as opposed to classes. DI works best at a level of abstraction higher than that of individual classes.

Many of the dependency injection examples you’ll find in a typical web search or documentation-trawl neglect to mention this key fact. The biggest benefit of dependency injection is loose coupling. Loose coupling is very important between the large-scale components of a system, but can be an anti-goal at the class level where high cohesion is a valid quality to pursue. The creation of objects in a loose coupling scenario should be delegated to a builder, such as an IoC container, but in a high-cohesion scenario you’re really looking more towards a closely-related class to do the creation and configuration of an object.

The ‘factory’ lifecycle model options supported by many containers could very easily encourage a proliferation of ‘inside out’ applications where the IoC container has responsibility for creation of far too many classes of objects. (The example I just saw described ‘Button’ as an example of a class that would use a factory lifecycle.)

The responsibilities of the container should be restricted to wiring together the bigger pieces, such as network interfaces or data layers, that can feasibly be used independently of each other. Putting the responsibilities associated with creating other, tightly-integrated lower-level classes into the container as well gives the container ‘responsibility bloat’ in my opinion. I doubt the authors of the existing dependency injection tutorials intended any different, but I guess it is hard to come up with examples of valid components with factory-style lifecycles.

Dependency injection containers for smaller applications

I don’t know if it is just me suffering a bit of ‘not invented here’ syndrome, but the available dependency injection containers for .NET seem fairly awkward when building smaller systems. I think DI containers keep architectures nice and clean, and the drawbacks they suffer in small applications are generally related to the configuration overhead.

Only a few popular containers have popped up in .NET land, and only time will tell whether any will become a de-facto standard. Castle Windsor has treated me fairly well, but it limits each component to providing a single service, something I’ve attempted to address myself but which runs quite deep into the architecture and won’t be fixed prior to the next official release.

Ruby is graced with a nice clean container called Needle – the feature that got me looking at Needle is one which allows components to be registered using Ruby ‘blocks’ – essentially, anonymous delegates or lambda expressions in C#/.NET land:


container.Register<ILogger>(
c => new FileLogger("foo.log"));


Here, the container gets an anonymous delegate that it can use to create an implementation of the ILogger service. The parameter ‘c’ passed to the registration delegate is a reference back to the container itself. Because the delegates are evaluated lazily, when components are requested, there is no need for registrations to be in order:


container.Register<IDatabase>(
c => new SqlDatabase(c.Resolve<ILogger>()));
container.Register<ILogger>(
c => new FileLogger("foo.log"));


This style of configuration appeals quite a bit to me for wiring up simple applications that don’t need much in the way of dynamic configuration but where the dependency injection pattern is still a useful structuring methodology.

Something lost in C# however, that Ruby gains from being an interpreted language, is the ability to make tweaks and changes post-deployment. For this perhaps the typical XML-based configuration is still the best way to go, however it would be a better approach in my mind to use the XML config as an override, rather than a complete description of the system.

The new ObjectBuilder in Enterprise Library 3.0 seems pretty nifty too, but puts me right off XML as a configuration syntax. It is just so hard to see the basic configuration information amongst all of that markup…

Perhaps there is room in the tower of Babel for a very, very small configuration DSL? Interested to hear whether anyone has come across something like this.

Function containers – amusing and possibly useless.

A few nights ago I was playing with the implementation of lambda expressions in C#3, and started to wonder how they could be used to lighten up some of the GoF patterns… An interesting, but probably useless outcome of the process was this was the ‘function container,’ which can be used to ‘cheaply’ implement factories.
Each factory gets its own creation delegate, a function signature that produces the product of the factory from some initialisation arguments:

// Person is a POCO
delegate Person PersonFactory(string name);

This delegate can be implemented using a lambda expression, method or anonymous delegate, e.g.:

name => new Person(name)

In this simple form it is a snap to add factories external to each of the domain object types, but the opportunity to inject more complex creation logic is maintained. To tie together the resulting proliferation of delegate expressions, a typed container is used:

FunctionContainer factories = new FunctionContainer();
factories.RegisterFunction<PersonFactory>(name => new Person(name));

Later the factories can be retrieved from the container and called:

Person newPerson = factories.Func<PersonFactory>().Call("Henry");

The ‘Call’ syntax is a bit of hacky generic magic that makes me think back to C++ days past… The return type of the FunctionContainer.Func() method is not the registered delegate itself, but a wrapper exposing the delegate through a property named Call:

// ICallable<TDelegate> exposes a TDelegate through a property called Call
ICallable<TDelegate> Func<TDelegate>();

I can’t see myself putting this to use in a real application, but the (often fairly inconvenient) fact that delegates in .NET get their own type regardless of their signature can obviously be put to some kind of use. More to come I guess!
By the way, the ‘automatic factory’ just coincidentally gave its name to this blog by reminding me of a neat story of the same title by Philip K. Dick!