1

Possible Duplicate:
Arguments against Inversion of Control containers

Using IoC (or Dependency Injection, DI) really helps in the creation of reusable components. DI also has benefits, it has been claimed, for testing your classes.

But, what is the purpose of the container that IoC/DI alone doesn't already bring to the table? Since there is a cost involved it would be nice to be able to tell when that cost becomes justified.

Community
  • 1
  • 1
Arne Evertsson
  • 19,693
  • 20
  • 69
  • 84

4 Answers4

2

The "container" in IOC systems is the component that contains the mappings for how to resolve dependencies. For example it would know that when a dependency of a interface of IFoo was asked for it would resolve to FooImpl.

You typically have to perform these mappings somewhere. Either through a config file, annotations or other runtime components.

You typically get all resolution from such a container. It is also sometimes called a kernel.

ryber
  • 4,537
  • 2
  • 26
  • 50
  • The container was one described to me like a bucket where all the implementation of the interfaces live, the IOC dips into the bucket when it needs to resolve a dependency – Burt Dec 17 '11 at 18:26
  • When does it become easier to resolve the dependencies outside of your own code? How can you tell when you need the container? – Arne Evertsson Dec 17 '11 at 18:35
  • 1
    I follow the "pain-in-the-ass" rule. As soon as having a container is less of a pain in the ass than not having one. I add one. – ryber Dec 17 '11 at 23:21
1

Dependency injection helps making your code maintainable, by moving the wiring of the way dependencies are wired to a single place in the application (the start-up path a.k.a. Composition Root). This is great, since that Composition Root has (just as everything else in your application) a single responsibility.

When your application will evolve and grow, you will see that classes themselves don't get much more complex by themselves (when adhering to the SOLID principles). The Composition Root however, will get big and complex very quickly, especially when using decorators to add behavior and doing things like registration by convention.

This is where a DI container comes in play. While the SOLID principles help you in designing an application that is flexible and maintainable, a DI container will help you keep the Composition Root maintainable. That's its sole purpose. Everything you do with a container can be done without it, but this will often result in a lot of repetitive and boilerplate code that is hard to read and hard to maintain.

So again, the sole purpose of a DI container is to make the composition root maintainable.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • Won't the composition root get big and complex no matter whether you keep in in code or in xml files? – Arne Evertsson Dec 18 '11 at 20:08
  • I prevent using XML configuration whenever possible, since it is ugly and there is no compile-time support. A good application design helps in keeping your composition root (CR) simple. For instance when designing the business layer around the [command pattern](http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91) and the [query pattern](http://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=92), you will see that almost everything can be registered automatically by the container. When your CR gets complex, look at your design, start using a DI container, or switch containers. – Steven Dec 19 '11 at 12:36
0

I think you need to keep the terminology clear:

IoC is Inversion of Control, which is the principle that the main flow of the system is handled by something outside the application core. That is there is a container of sorts that orchestrates the execution and there is the application code that encapsulates the business logic. The wikipedia article on IoC gives a pretty good explaination.

DI is dependency injection which is the idea that a unit of code does not new up its dependencies, but gets them from the code that instatiates the unit. Again wikipedia a has good article on DI.

Combining those two means having something centralized that inverts that takes the responsibility of instatiating everything and resolving dependencies. Whatever centrlized code does this is the IoC/DI container. You can write it yourself or use a off-the-shelf one.

Christian Horsdal
  • 4,914
  • 23
  • 24
  • The Wikipedia article on IoC states that "Dependency injection is the main method to implement Inversion of Control". It seems that the container falls outside of what IoC is? – Arne Evertsson Dec 19 '11 at 22:46
0

Containers responsibility is to manage instances.

Aleš Roubíček
  • 5,198
  • 27
  • 29