This is a very short post to draw your attention to the Agnostic IoC and Lucinq documentation that I have been putting together during recent weeks.
You can access this via the menu’s at the top. If there is anything you need clarifying or would like documentation on, please let me know, your feedback is invaluable.
So – here is the second in the series of introducing Agnostic IoC. In this topic I wanted to cover a standard problem that (particularly as developers of a proprietary system such as Sitecore) face regularly.
I have always (for convenience as much as anything) utilised the global.asax.cs to perform my container setup. This is particularly easy as I usually have this class inherit an interface. This conveniently allows me to cast the application instance as my ‘IContainerAccessor’ to allow me to get at the container. This (for Sitecore / Umbraco) in particular is inherently flawed in that, the vendors of third party systems also often mess with these classes – Sitecore for example (off the top of my head) have changed it in 2 or 3 of the last major releases and possibly some of the minors. I have seen (in implementations such as Glass Mapper), the use of WebActivator to overcome this too – this is a perfectly reasonable alternative.
In designing Agnostic IoC, I wanted to consider the possibility of having Agnostic scan the loaded assemblies for containeradapters and register them for itself, here is an example of the test container adapter we are going to use.
Just a quick post to announce, the initial release candidate for Agnostic IoC is now available on the Cardinal Nightly Feed (soon to be Nuget)
The initial release provides support for the following IoC containers:
- Castle Windsor
- StructureMap (experimental at present)
Support for other containers can easily be added by creating a class deriving from the ContainerAdapter class and overriding the necessary methods. Use one of the existing ContainerAdapters as an example.
The nuget packages can currently be found on the Cardinal Nightlies Nuget Feed
The source code can be found here Cardinal Github Page
As a few of might already know, we started a project a short while back to overcome the difficulties developers face when building reusable modules for systems. This project was centered on the need to continually write our inverted dependency calls manually to avoid ties to an IoC container such as Autofac / Windsor. Recently a client of mine and also a friend have independently approached me about this subject. The former wants to commission me and Simon from the team here, to help them out on a build for a client of theirs, this client has asked that we use Autofac as the dependency container and Glass Mapper as the ORM. The second wants to be able to use Glass Mapper with their current implementation, they however use structure map.
It would have been a reasonable enough task to duplicate and modify the Windsor implementation from github twice to allow this to happen, but I fancied a challenge and thought this would be a good test of the Agnostic IoC extensions that I have written and talked about Here. After all, it is the near perfect use case for such an implementation – 1 framework with a choice of end IoC containers depending on the client.
What is Agnostic IoC?
Agnostic IoC is a set of extensions that aims to abstract the IoC container away from the final consuming implementation, you write your code against Agnostic IoC and it adapts the calls to the real IoC. You can initialise it from self discovery on adapters or simply push in your own already built container. It in many cases will not replace your own IoC implementation, it’s primary focus is to allow you to ship your reusable modules so others can enjoy them without tying them to particular versions of IoC containers. If the IoC container of your choice isn’t supported, it is quick and easy to write an additional one simply by inheriting from the abstract ContainerManager class. When consuming the application, you simply need to install the nuget package that matches your chosen IoC. If you need to get at any of the original functionality – the ContainerAdapter is a generic in its own right, you can simply cast something like myContainerManager.Container as IWindsorContainer to get back to the original container (that said – you can push your own in so not sure how much use it will be 😉 )
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.
Some time ago I decided that Autofac was my IOC of choice. After spending a few years using Unity I knew I wanted more and, after evaluating a few libraries, Autofac fitted how I work.
Aside from the usual property and constructor injection stuff we would expect from any IOC library, Autofac has quite a few additional features that can make coding life a lot easier. And in less lines of code.
One thing I love to show people who have used IOC for a while is my use of delegate factories.
The wiki post from the Autofac project is here: https://github.com/autofac/Autofac/wiki/Delegate-Factories.
I think the title says it all!
Let components create instances of other components without hand-coding factories.
So, in short, we can use Autofac as a factory and take a dependency on that factory instead of the type itself. This is quite powerful as it means we can create instances of our dependency within our component as needed.