Is there a problem with having more than one IoC container in the solution?

Question

I am creating a multi-tier application with ASP.NET MVC interface and ServiceStack.NET web services.

I started using Ninject for DI at the beginning of the project. Now when I add ServiceStack to the mix, I am curious if there are any possibilities for future problems:

The ServiceStack library by default uses Funq as an IoC container. Everything seems to be working fine, but I wonder if I will see any problems with having two IoC containers in one application?

Answer 1

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

Registration in Funq is non-invasive, i.e. you must manually register your dependencies, as it does not scrupulously scan all your assemblies, registering all the dependencies found. If you decide not to use Funq and use a different IOC by introducing an IContainerAdapter and delegating a different IOC, then your Funq dictionaries of the cached delegates will be empty (i.e. skip the cache), and ServiceStack will simply ask for your preferred IOC for the dependency.

The only thing to keep in mind is that the web services themselves are registered and automatically connected to ServiceStack and not to your preferred IOC container, so in this case your IOC acts more like a dependency store.

Answer 2

I do not know if this will break in the future, but it can. To minimize the risk, you can try to do a unit test of your injection routines, so when you make changes, you will have a mechanism to ensure that your injection routines will still work.

As a rule, I think that consistency improves quality, so I would consider code refactoring to use one provider. I use Ninject and I have 4 modules for injecting services and repositories. Each module contains 10-20 injection procedures - I can reorganize them within an hour. If your project is the same size, then refactoring and using the same IoC.

Edit I have never used ServiceStack.Net, but how much is your project dependent on this structure / toolkit? Most likely, in the near future you will replace it with something else? How much does this depend on your MVC project? I am trying to think of a scenario where the maintenance costs of using one IoC will be higher than the maintenance costs of using another IoC.

Looking at Ninject, there is an extension Ninject and Ninject MVC 3. The extension simplifies the work and does not conflict with anything else. In my case, I had to replace the standard Ninject with Ninject MVC 3, because for me it did everything that the standard version did (+ optional), and it was easier to configure.

Answer 3

I would say it depends.

If the IoC framework you use have different dependencies without overlapping, I don't see any problems. If, as I suspect, you probably have to double the IoC registration, then I think it depends on how you manage the lifetime of your dependencies.

If all of your dependencies are temporary or created using custom factory methods, you'll probably be fine. However, everything can become unpredictable after you start trying to transfer single or instance-dependent to the web request into the mixture.

I have never used Funq before, but if it's a convenient IoC container, I would recommend removing Ninject from your project, if possible. Besides eliminating the prospects of your application, with which it is difficult to track errors, it will keep your code much drier and more consistent.