Dependency Injection Containers for Small/Medium Applications

Posted by Nicholas Blumhardt | April 08, 2007 16:40

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.

Disclaimer: These articles represent the opinions of the authors and may not match the official position of Ubik Systems Pty. Ltd. Confirmation should be sought on all matters involving professional advice.