Is there an issue with having more than one IoC Container in a solution?

I am building a multi-layer app with with an ASP.NET MVC front-end, and ServiceStack.NET web services.

I began using Ninject for DI at the start of the project. Now that I am adding ServiceStack into the mix I am curious if there is any potential for future problems:

The ServiceStack Library uses Funq as its IoC container by default. Everything 开发者_运维知识库seems to be working normally, but I am wondering if I will see any issues with having two IoC containers in the same application?

---

Not really in the case of Funq (which is used in ServiceStack) as its a statically bound IOC which is more like a C# Dictionary full of cached constructor delegates than an full-featured IOC. It is included in source form in ServiceStack and was chosen because it is very fast (i.e. near native speeds): http://www.codeproject.com/Articles/43296/Introduction-to-Munq-IOC-Container-for-ASP-NET.aspx

The registration in Funq is non-invasive i.e. you have to manually register your dependencies as it doesn't indiscriminately scan all your assemblies registering all dependencies it finds. If you choose not to use Funq and use another IOC by injecting an IContainerAdapter and delegating to another IOC, then your Funq dictionaries of cached delegates will be empty (i.e. cache miss) and ServiceStack will simply ask your preferred IOC for the dependency instead.

The only thing to keep in mind is, the Web Services themselves are registered and auto-wired by ServiceStack and not your preferred IOC container, so in this case your IOC acts more like a repository of dependencies.

---

I would say - it depends.

If the IoC frameworks you're using have different dependencies with no overlap then I don't see any issues. If as I suspect though, you're effectively having to double-up your IoC registrations then I guess it depends on how you're managing the lifetime of your dependencies.

If all your dependencies are transient or created through custom factory methods then you'll probably be OK. However things may well get unpredictable once you start trying to throw singletons or 'instance per web request' dependencies into the mix.

I've never used Funq before, but if it's a capable IoC container I'd recommend removing Ninject from your project if possible. Aside from eliminating the prospect of your application having hard to track bugs, it will keep your code much more DRY and consistent.

---

I don't know whether it'll break in the future, but it might. To minimise the risk, you could try unit-testing your injection routines, so then when you introduce the changes you'll have a mechanism to ensure that your injection routines still work.

Generally, I think that consistency improves quality, so I would consider refactoring code to use a single provider. I use Ninject and I have 4 modules for injecting services and repositories. Each module contains 10-20 injection routines - I can refactor these within an hour. If your project is of similar size, then refactor and use a single IoC.

Edit I have never used ServiceStack.Net, but how dependent is your project on this framework/toolkit? Are you likely to replace it with something else in near future? How dependent is it on your MVC project? I'm trying to think of a scenario where maintenance cost of using one IoC will be higher than maintenance cost of using another IoC.

Looking at Ninject, there is Ninject and Ninject MVC 3 extension. The extension simplifies the job and doesn't conflict with anything else. In my case, I had to replace standard Ninject with Ninject MVC 3 because for me it did everything the standard version did (+ extra) and was easier to configure.