How IoC Container implements Dependency Injection compared to how I would implement it

To do Dependency Injection, I could create a generic dictionary of different types of db connections and then instantiate one type dynamically through reflection before passing it to the object's constructor that needs it.

What difference and benefit does it bring when using an IOC Container since It doesn't make my stuff more independant than the first solution. How the IOC Container would do internally ? Is it different from the first solution ?

How would you impl开发者_开发技巧ement DI without container ? When would you switch to an IoC Container ?

I mean is there other way to implement DI other than the one I have thought about so that I could use the best way ?

---

I suppose a container does a lot of the boiler-plate code for you. For example, it does exactly what you said, instantiating a class based on the reflected behavior. Many containers also allow you to explicitly configure your system based on config files.

IOC or DI are only concepts. IOC/DI concepts give you the "indenpendency" that you favor. The actual implementation can vary. You can do it without using a third-party container -- or write your own. Or you can leverage the features provided by a well-tested third-party container.

If you just want to inject different types of db connections, they you have a very small need for IOC/DI. In general IOC/DI (beware, not the container, which is just an implementation of IOC/DI) gives you totally configurable software, aids in unit testing (by injecting stubs), self-configuration, etc.

Typically IOC/DI is necessary when:

1. your software is so large and complex that no single person has it all in his head, or
2. has so many different configurations that you don't want customized builds, or
3. is so inter-dependent among the pieces that you find it difficult to test each piece alone

---

Dependency Injection has nothing to do with dictionaries. As Nicholas Blumhardt explains in an excellent blog post, you need a completely different mental model for DI.

DI is loose coupling through the application of the Constructor Injection and Composition Root design patterns. When a DI Container enters the picture it does so via the Register Resolve Release pattern.

So if a class requires a db connection, it requests one through the constructor.

---

Nothing says you need to use an IoC container, it's just that IoC containers are pre-built, and you don't have to write the code yourself. This means you can concentrate on building your app, and not your own DI system.

It's like building your UI or using a third party control. Both work, it just depends on where you want to spend your time. I know I don't really care much about building my own DI system, so I would rather use a pre-built one.

You might as well ask, why use a framework at all when you can write directly to the OS APIs. It's all about improving reliability (by reusing code someone else has already written and spent lots of time making sure was bug free) and boosting your productivity (by not having to write everything yourself).

EDIT:

There are lots of ways to implement DI. You could always look at all the containers that are out there, and how they work. They're all open source, and the source code is available.