If you’re looking for the Autofac .NET IoC container, head on over to the project site.

With the launch of the new Ubik Systems website only days away, I’ve started adding new posts directly to that site. Come on over and take a look! Nick.

Something I have come back to a few times when explaining the benefits of Dependency Injection is how the pattern relates to Service Locator. Martin Fowler thinks Service Locator is a better choice when you’re building a single application, while Dependency Injection can be more appropriate otherwise.

You can get a good idea of how the two patterns work by reading his article. I don’t agree with his conclusion, in part because when setting out to build an application you often end up building a small suite of related apps: the main front-end you always intended to write, perhaps some administrative tools, perhaps some data import tools, perhaps some back-end services that run on a schedule. Once this happens, Dependency Injection beats Service Locator hands-down.

The oft-quoted drawback of Service Locator is that all the components depend on the locator. To me this isn’t a big deal. The problem dependency that Service Locator introduces is a much larger-scale one – the components, through the keys that they use to locate associated services, create an implied system architecture that is hard to change from outside the components themselves.

For a simple example, let’s say the Authenticator component and the Auditor component both look up the service “logger”. By using the simple key “logger” in both cases, these components implicitly depend on the same object. In a different environment, we may require the the Auditor logs to the database, and the Authenticator logs by sending email to an administrator. Using a service locator we have a couple of choices:

1. Use a different scheme for the keys, e.g. “logger/authenticator” and “logger/auditor” – now our ’simple’ service locator is getting more complex and we have to sort out in advance how our service naming scheme works.
2. Build the flexibility into the logger – use different log sinks for different sources. This isn’t a bad option, but is essentially a case of moving general functionality out of our architecture into specific functionality within the components, thus adding more complexity to the system.
3. Change the Authenticator and Auditor so that they can be initialised with a specific logger when the application starts up.

To me, option number 3 is the common-sense choice: after all, it makes use of the most basic features of the programming language we’re working in and saves us from creating our own more complex structures on top of the language.

Coincidentally option number 3 is Dependency Injection. By having all of our components accept their dependencies as constructor or property arguments, they can be wired up in arbitrary ways without any need for code changes.

That’s really as far as you have to take dependency injection – and while the application is small, your startup code can just create and wire up components as needed. Beats Service Locator for the simple fact that you’re sticking to the built-in dependency mechanisms of your programming language, and later on, if you want to use a dependency injection framework to simplify the configuration code, you can do so without changing your components.

Platform and language monoculture is a big issue in established software companies today. Perhaps a lack of it is one of the defining factors identifying the new ‘agile’ development outfits that have popped up so far this decade.

The Java and Microsoft ’shops’ are the best examples – companies that are willing, through principles of economy, to put all of their eggs in the one technological basket.

I recently overheard: “we can’t adopt application X because that would require training someone in Java.” Perhaps that is the reason that training is so often only given lip service and is considered to be of little real value? Training in a new facet of a platform you already know doesn’t really take you anywhere new. Significant insights most often come to me when I step back from my own work and see how other people are tackling the same problems.

Familiarity with multiple platforms and tools can give you a lead over the competition. NUnit, CruiseControl.NET and NHibernate have been being used effectively for quite a while now, by the .NET developers who looked over the fence and saw the advantages being enjoyed in Java-land. Microsoft have finally come to the party with Team Foundation Server and Linq to Entities – but now the competitive advantage is gone and a new set of not-so-secret weapons is needed to stay ahead.

The rationale for keeping the set of technologies in use in any one development team small is a sound one, but I think that taking this wisdom without a healthy grain of salt can lead to mediocre systems built using sub-optimal tools.

…what an ‘FBox’ is…

The FBox source code is the implementation behind this article. Why not elaborate a bit more…

The ‘Factory’ patterns (Factory Method, Abstract Factory…) can be really useful. For every class or hierarchy of classes that you’ll be creating from different pieces of code, you define another class (the factory) that is responsible for instantiating and initialising the products. Then, if the creation requirements of the product change, there is only one piece of code that needs to be updated. E.g.:

// The Person class is the product.
class Person
{
  public Person(string name) { ... }
}

// Later...
PersonFactory factory = new PersonFactory();
Person john = factory.Create("John");

OK so despite the obvious need for a biology lesson, what’s going on here is really simple. If we ever need to add steps to the creation process, it is easy to change the Create() method without affecting the pieces of code that use it:

public Person Create(string name)
{
  Person result = new Person(name);
  Logger.Log("Created new person named: " + name);
  return result;
}

Or even more interesting:

class FreakyPerson : Person { ... }
...
public Person Create(string name)
{
  if (name == "John")
    return new FreakyPerson(...);
  else
    return new Person(name);
}

In the second example, we introduced a whole new class – a subclass of person – that we’ll create under certain conditions but which the original users of the factory don’t need to know exists at all! With a lot of pieces of code potentially creating Person objects, this could be very inconvenient to do had we not used the factory.

Generally you’d only bother with a factory if you knew or suspected that you would need to vary the actual concrete implementation in this way. Unfortunately you can’t always foresee the kinds of changes that could be elegantly made with such facilities in place.

Anyway – the downside to using a factory, of course, is that it introduces quite a bit more code that in 99% of cases won’t do anything interesting. The example factory above is extremely oversimplified: most of the time, this kind of factory (a Factory Method) would be implemented using several classes and interfaces, with the associated plumbing to put it all together. With the appropriate using declarations, namespacing, etc, that could be 50 lines of code. You could just create one giant Factory class, with a method for every kind of product (CreatePerson(), CreateCat(), CreateMouse()) but that is going to create a large amount of coupling – everything dependent on the factory – and won’t be much fun in modular systems where Cat and Mouse aren’t even defined in the same assemblies…

…which is why you don’t see Factory being used extensively in real applications except those big fat overblown ‘enterprisey’ monstrosities that we all want to steer clear of.

I think that’s a shame, because the benefits in terms of flexibility and elimination of repetition can be great. Isn’t DRY (Don’t Repeat Yourself) something of a mantra within the agile movement?

FBox is pretty simple but might solve this dilemma. You need to create an FBox for every family of related products you’re going to create (I should mention at this point – the class that implements FBox is called ‘FunctionContainer’):

FunctionContainer animalFactory = new FunctionContainer();

You might create one FBox for domain objects like animals, one for GUI widgets, etc. – these could be static properties on a particular class – whatever.

The next step (we’re creating factories for Person, Cat and Mouse) is to declare a delegate that takes the place of the ‘Create’ method in a traditional factory:

delegate Person CreatePerson(string name);
delegate Cat CreateCat(string name, Color color);
delegate Mouse CreateMouse(int whiskers);

You then implement these ‘factories’ by registering a simple lambda expression implementing each delegate:

animalFactory.RegisterFunction<CreatePerson>(
  name => new Person(name));
animalFactory.RegisterFunction<CreateCat>(
  (name, color)=>new Cat(name, color));
...

So each factory has cost us two lines of code. To use the factory, we just get it out of the FBox and call it:

Cat tiger = animalFactory.Func<CreateCat>().Call("Tiger", Color.Gray);

(My Tiger is of a non-standard hue…)

The great thing about this implementation over other ‘generic’ factory approaches is that the Call(…) statement above is strongly typed. It requires a string and a Color parameter – if these are not provided, you’ll get an error at compile time rather than runtime.

To break it down:

1. animalFactory.Func<CreateCat>() looks up the expression that we registered: (name, color) => new Cat(name, color). It gets returned wrapped up in an object that exposes it through a property called ‘Call’.

2. Call(“Tiger”, Color.Gray) retrieves our expression from the Call property, and invokes it with the parameters we’ve given.

The actual code that creates the cat is the expression we registered using animalFactory.RegisterFunction().

Two lines of code probably isn’t too much to ask in return for a lot of flexibility. Let’s say we need to do more than just create an instance of the Cat class. The solution is simple – create a fully-blown function to do the work:

class CatFactory
{
  public static Cat CreateCat(string name, Color color)
  {
    // Do whatever needs to be done to create a cat...
  }
}

…and register it instead of the original expression:

animalFactory.RegisterFunction<CreateCat>(
  new CreateCat(CatFactory.CreateCat));

The old code that we used to create our tiger will now use the new CatFactory.CreateCat function instead of the simple expression. Voila! You can even vary the actual function used at runtime…

I’ve never used this in an app, and never seen it done elsewhere (tell me if you do!) so I can’t say I’ve explored the possibilities or the drawbacks.

Just for the morbidly curious the source code for the FBox function container can be downloaded here. It is built using the Orcas March CTP but the library itself could be compiled under VS2005.

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

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.

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!