About seven years after everyone else got it I think I may have finally gotten it too. That final letter in TDD may be about Design as anything else!

I've never written anything in Java so the offer to deconstruct/reconstruct and deploy a Java EE website based on Struts sounded a death march. We brought in a dedicated contractor who struggled some with Tomcat instances and lock down. Difficulties correctly called.

We needed to work out which code (including SQL) was being called for each page on a public facing website. I didn't fancy clicking through the website and scribbling down the execution path, which someone suggested and I'd no idea whether there existed anything that allows bytecode instrumentation without modifying the Java source. A quick look at Spring and AspectJ indicated that neither are particularly lightweight. 

This looked promising though: Javassist is a load-time reflective system for Java. IBM developerworks has a handy guide to aspect-oriented changes with Javassist. Still not sure, however, how to tie method calls to database calls.

In the end I wrote some code generation utility to add logging for both method calls and database calls (via OJDBC), using Regex to identify each. The key thing here was that no single method in the C# tool was written without first writing a test. Not only is this the first thing I've ever written with 100% code coverage but I managed also to maintain the discipline needed to avoid squeezing in some code without first having a failing test. Each initial test was followed with a passing test using the very simplest solution, writing a second failing test by varying parameters, before completing the implementation.

Once applied to production code I then realised that I'd made no design decisions. Absolutely none! This is something I'd never previously considered. I expect this very same light bulb went on too for many folks almost a decade ago. If you only ever write the next method required the design just emerges. Also, the simplest possible solution in this case meant there were no redundant lines to delete at the end. Just very satisfying indeed.

Our favourite piece of code seen recently is from a while ago: Building an IoC container in 15 lines of code. We like it because the intent is really very clear. Every now and then we find some use of Spring.NET or mention of IoC. Sometimes wonder whether it's necessary or being used because Developer-X wants to indicate sophistication. So then as a refresher we often end up here: Inversion of Control Containers and the Dependency Injection pattern. Written 35 Internet Years ago.

Looking at the way applications are written circa 2008 it appears IoC is reasonably common and therefore time to incorporate. Known advantages:

• Decoupling
• Service Orientation (is this repetition of the first?)
• Testability
  • Allows mocking

The fact that we've neither been tripped up by object graphs nor troubled with dependency suggests not having done anything nearly enterprise enough. That, rather than an eidetic view of object relationships. Still, there's an argument for trying to incorporate a different approach into the ordinary as a means for seeing the ordinary for being less than splendid.

Right, so which one do we go for?

• Windsor (Castle Project MicroKernal)
• StructureMap
• Autofac

The nice thing about Autofac is that it's capable of using a delegate or Lambda Expression rather than reflection for component creation. As stated elsewhere, .NET 3.0 style. We like.

Notes:

Useful to make explicit the difference between Inversion of Control and Dependency Injection. Hint: The latter is a specific form of the former. Nice one, Wikipedia!