DI

Agnostic IoC Pt II – Container Self Registration

/ Nat / Leave a comment

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.
Continue reading →

Advertisements

Agnostic IoC – Released

/ Nat / Leave a comment

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
  • Autofac
  • Unity
  • StructureMap (experimental at present)

Other containers
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.

Nuget
The nuget packages can currently be found on the Cardinal Nightlies Nuget Feed

Source Code
The source code can be found here Cardinal Github Page

Further Reading

Agnostic IoC – Introducing Container Agnostic Dependency Injection

/ Nat / Leave a comment

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.
Continue reading →

Make the most of IOC – Delegate Factories

/ simonproctor / 2 Comments

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.
Continue reading →