Monday, April 19, 2010

Preventing IoC Configuration Chaos

After working with tightly coupled (read as "welded") existing code bases in many previous companies, when given a green fields opportunity, I want to ensure thorough use of IoC.  This is essential to allow automated testing. Automated testing is essential for efficient agile development.

The problem is, when you write a large system, that equates to a large config file.  Actually it will be an enormous config file.  This is unacceptable in my opinion for several reasons:

  1. Large XML / Config files are annoying to maintain, and easy to get wrong.
  2. There's no compile time checking and fast feedback for XML / Config files.
  3. Most of the time the config is static, no one will want to change it at runtime for a production system (excluding unit testing).
  4. The config is owned and stored in the app/web config but some of your DLL's are designed to be reused independently and whenever they are consumers need to find an example of config and copy and paste it.
So a good solution needs the following attributes:
  1. By default (with no consumer code or config) any individual DLL must own its own default config. If a consumer takes and consumes your DLL that's all they need.
  2. By default the IoC container must be preconfigured to return production instances.
  3. Any hard coded default must be override-able by config.
  4. It must be easy to trigger IoC container intitialisation on application startup.
  5. Ideally the consumer shouldn't have to maintain a list of DLL's to intitialise.
Here's some sample code that I have come up with that attempts to solves these with StructureMap.
The basic idea is that all interfaces and abstracts registered with IoC for the primary purpose of unit testing should be configured with code in a DLL specific "Startup" class.  Each Referenced assembly in the current AppDomain is "visited" using a psuedo-visitor pattern and its Startup class is located and executed.

Each assembly that contains IoC registrations that need to evaluated must be decorated with this custom attribute.

[assembly: AssemblyInitialization(typeof(MamalsStartup))]
This points to the startup class containing the code registrations. Here's an example of a Startup implementation:

public class MamalsStartup : IStartup
        private readonly object syncRoot = new object();

        public bool IsInitialized { get; private set; }

        public void InitializeObjectFactory()
            if (this.IsInitialized)

            lock (this.syncRoot)
                if (this.IsInitialized)

                var factory = ObjectFactory.Container;
                factory.Configure(config =>
                    config.For<ICat>().Use<Cat>().Named("Felix").OnCreation(c => c.Name = "Felix");

                FrameworkInitialise.ObjectFactoryInitializeCompleted += this.OnObjectFactoryInitializeCompleted;
                this.IsInitialized = true;

        public void Shutdown()
            // Trigger any shutdown / cleanup logic

        private void OnObjectFactoryInitializeCompleted(object sender, System.EventArgs e)
            // You can do any singleton registration here. Or any registrations that require other registrations have been completed.
            FrameworkInitialise.ObjectFactoryInitializeCompleted -= this.OnObjectFactoryInitializeCompleted;
Notice how I have made an event that fires once all IStartup.InitializeObjectFactory this is to allow complex registrations that require instances of standard objects or singletons to be available.  It also useful for kicking off any other intialisation that may be required.  There's also a ShutDown method, this is useful for tidying up any singleton registrations that implement IDisposable or other cleanup logic.

To trigger the whole process the consuming code only needs one line of code:

// Invoke Initialise to trigger the process of "visiting" all assemblies referenced and calling each assemblies
// startup class to configure the IoC container.

Here's the initialize method:

/// <summary>
        /// Initializes the AppDomain assemblies that have the <see cref="AssemblyInitializationAttribute"/>.
        /// </summary>
        public static void Initialize()
            if (isInitialised)

            isInitialised = true;
            var current = AppDomain.CurrentDomain;
            current.AssemblyLoad += OnAssemblyLoad;
            current.ProcessExit += ProcessExit;

            var assemblies = (from assemblyName in Assembly.GetEntryAssembly().GetReferencedAssemblies()
                              where assemblyName.FullName.StartsWith(AssemblyPrefix, StringComparison.InvariantCultureIgnoreCase)
                              select Assembly.Load(assemblyName))

            var list = new Dictionary<int, AssemblyInitializationAttribute>();
            FindInitAttribute(assemblies, list);

            // Finding and accessing the AssemblyInitializationAttribute will instantiate it and its ctor will trigger that assembly's startup class.
            // By the time this point is reached all assemblies have had their Object Factories configured.
            var handler = ObjectFactoryInitializeCompleted;
            if (handler != null)
                // Some Assemblies may be interested to be informed when all others have had their Object Factories configured.
                // This will allow them to perform any other intialisation code that requires dependent assemblies to be configured first.
                handler(null, EventArgs.Empty);

No comments:

Post a Comment