Why do I need an IoC container as opposed to straightforward DI code? [closed]

Answer 1

Dependency Injection in an ASP.NET project can be accomplished with a few lines of code. I suppose there is some advantage to using a container when you have an app that uses multiple front ends and needs unit tests.

Answer 2

The biggest benefit of using IoC containers for me (personally, I use Ninject) has been to eliminate the passing around of settings and other sorts of global state objects.

I don't program for the web, mine is a console application and in many places deep in the object tree I need to have access to the settings or metadata specified by the user that are created on a completely separate branch of the object tree. With IoC I simply tell Ninject to treat the Settings as a singleton (because there is always only one instance of them), request the Settings or Dictionary in the constructor and presto ... they magically appear when I need them!

Without using an IoC container I would have to pass the settings and/or metadata down through 2, 3, ..., n objects before it was actually used by the object that needed it.

There are many other benefits to DI/IoC containers as other people have detailed here and moving from the idea of creating objects to requesting objects can be mind-bending, but using DI was very helpful for me and my team so maybe you can add it to your arsenal!

Answer 3

Personally, I use IoC as some sort of structure map of my application (Yeah, I also prefer StructureMap ;) ). It makes it easy to substitute my ussual interface implementations with Moq implementations during tests. Creating a test setup can be as easy as making a new init-call to my IoC-framework, substituting whichever class is my test-boundary with a mock.

This is probably not what IoC is there for, but it's what I find myself using it for the most..

Answer 4

I'm a fan of declarative programming (look at how many SQL questions I answer), but the IoC containers I've looked at seem too arcane for their own good.

...or perhaps the developers of IoC containers are incapable of writing clear documentation.

...or else both are true to one degree or another.

I don't think the concept of an IoC container is bad. But the implementation has to be both powerful (that is, flexible) enough to be useful in a wide variety of applications, yet simple and easily understood.

It's probably six of one and half a dozen of the other. A real application (not a toy or demo) is bound to be complex, accounting for many corner cases and exceptions-to-the-rules. Either you encapsulate that complexity in imperative code, or else in declarative code. But you have to represent it somewhere.

Answer 5

Using a container is mostly about changing from an imperative/scripted style of initialization and configuration to a declarative one. This may have a few different beneficial effects:

• Reducing hairball main-program startup routines.
• Enabling fairly deep deployment-time reconfiguration capabilities.
• Making dependency-injectable style the path of least resistance for new work.

Of course, there may be difficulties:

• Code that requires complex startup/shutdown/lifecycle management may not be easily adapted to a container.
• You will probably have to navigate any personal, process and team culture issues -- but then, that's why you asked...
• Some of the toolkits are fast becoming heavyweight themselves, encouraging the sort of deep dependency that many DI containers started off as a backlash against.

Answer 6

I just so happen to be in the process of yanking out home grown DI code and replacing it with an IOC. I have probably removed well over 200 lines of code and replaced it with about 10. Yes, I had to do a little bit of learning on how to use the container (Winsor), but I'm an engineer working on internet technologies in the 21st century so I'm used to that. I probably spent about 20 minutes looking over the how tos. This was well worth my time.