Agnostic IoC – Introducing Container Agnostic Dependency Injection

So – in this post I will cover my latest (and somewhat marmite) solution to the issue of managing dependencies when your clients insist you use the IoC container of their choice.

Many times in my development career I have had to switch the use of IoC containers due to the client having defined standards on what they would like you to use. So far, I have already had the opportunity to implement sites using Autofac, Ninject, Windsor & Unity. I fully expect there will be more!

In addition to this, I have a number of modules now available that I have deliberately avoided using a DI framework due to the above (it is a personal bug bear of mine for example that Sitecore’s social connect module ships with Ninject).

For all of the reasons above – I have created Agnostic IoC. It is a simple module that handles the instantiation of IoC containers and allows your code to rely on its own IContainerManager to resolve your dependencies.

In use:
In order to install the container of your choice, you simply need to inherit from the ContainerAdapter abstract class, I have created a default Windsor and Unity container adapter to make life easier

public class TestWindsorContainerAdapter : WindsorContainerAdapter
{
   public override void Setup()
   {
      Container.Register(Component.For().ImplementedBy());

      Container.Register(Component.For().ImplementedBy().Named("DependentClass2"));
   }
}

The Agnostic IoC scans the AppDomain’s loaded assemblies to locate your ContainerAdapter and registers it for use

Then in your code you can simply use:

IContainerManager containerManager = new ContainerManager();
IMyInterface myObject = containerManager.Resolve<IMyInterface>();

If you wish to support multiple containers of the same DI container type & even different container types (yes you can also use different IoC containers in the same solution – though maybe not the best idea!!), simply override the ‘Name’ property in your adapter and call it using. The default one uses an empty string as the name.

IContainerManager containerManager = new ContainerManager(name);

This practice is not something I would suggest doing as a general ‘catch all’ approach, but when you need to support differing DI containers, it helps šŸ˜€

There will be nuget packages coming soon!!

Hope you find this useful šŸ˜€

Further Reading

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s