A quick morning post for any users of Agnostic IoC and anyone thinking about it.
If you have used it, you will have noticed that the binaries and namespaces referred to ‘Cardinal.IoC’. This was a decision made a long time ago, as the original idea for this project was to be part of a bigger ecosystem.
I took the decision well over a month ago that Agnostic IoC was to be de-branded and (due to large work commitments, house move and just life) I have finally managed to achieve this.
For existing users – this will mean that instead of ‘Cardinal.IoC’, it will now be ‘Agnostic.IoC’ at the start of the namespaces.
I think this is a great little utility library and hopefully it will continue to grow with you guys’ support.
Please do contact me with feedback, questions or general abuse 😀
Just a very quick post
This evening I released the source for Glass Mapper running on Agnostic IoC in a more useable format.
You can find it here
This is a great opportunity to get to grips with how Agnostic IoC can be used (especially with Sitecore) to give your modules the flexibility you desire them to have.
Please do feedback on your experience.
Nice quick post to announce support for Ninject in Agnostic IoC.
You can find more information on agnostic IoC from the links at the top of this page
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
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.