Dependency Injection Frameworks: Why do I care?

Question

I was reading over Injection by Hand and Ninjection (as well as Why use Ninject ). I encountered two pieces of confusion:

1. The inject by hand technique I am already familiar with, but I am not familiar with Ninjection, and thus am not sure how the complete program would work. Perhaps it would help to provide a complete program rather than, as is done on that page, showing a program broken up into pieces

2. I still don't really get how this makes things easier. I think I'm missing something important. I can kind of see how an injection framework would be helpful if you were creating a group of injections and then switching between two large groups all at once (this is useful for mocking, among other things), but I think there is more to it than that. But I'm not sure what. Or maybe I just need more examples of why this is exciting to drive home the point.

Answer 1

Dependency injection using most frameworks can be configured at runtime, without requiring a recompile.

Answer 2

I really like the autowiring aspect of some frameworks ... when you do not have to care about what your types need to be instantiated.

EDIT: I read this article by Ayende @ Rahien. And I really support his point.

Answer 3

Dependency injection can get really interesting if you get your code to the point where there are very few dependencies in the code at all. Some dependency injection frameworks will allow you define your dependencies in a configuration file. This can be very useful if you need a really flexible piece of software that needs to be changed without modifying the code. For example, workflow software is a prime candidate for this type of solution.

Answer 4

It allows you to easily test your code by mocking the interfaces that you need for a particular code block. It also allows you to easily swap functionality without breaking other parts of the code.

It's all about cohesion and coupling.

You probably won't see the benefit on small projects, but once you get past small it becomes really apparent when you have to make changes to the system. It's a breeze when you've used DI.

Answer 5

When injecting your dependencies without a DI framework you end up with arrow code all over your application telling classes how to build there dependencies.

    public Contact()
        : this(new DataGateWay())
    {
    }

But if you use something like Ninject all the arrow code is in one spot making it easier to change a dependencies for all the classes using it.

internal class ProductionModule : StandardModule
{
    public override void Load()
    {
        Bind<IDataGateway>().To<DataGateWay>();
    }
}

Answer 6

Dependency Injection is essential for the Component Driven Development. The latter allows to build really complex applications in a much more efficient and reliable manner.

Also, it allows to separate common cross-cutting concerns cleanly from the other code (this results in more reusable and flexible codebase).

Related links:

• Inversion of Control and Dependency Injection - Wiki
• Component-Driven Development - Wiki
• Cross-cutting concerns - Wiki

Answer 7

I still don't really get how this makes things easier. I think I'm missing something important.

Wouldn't it would be great if we only had to develop discreet components where each provided distinct functionality we could easily understand, re-use and maintain. Where we only worked on components.

What prevents us from doing so, is we need some infrastructure that can somehow combine and manage these components into a working application automatically. Infrastructure that does this is available to us - an IOC framework.

So an IOC framework isn't about managing dependencies or testing or configuration. Instead it is about managing complexity, by enabling you to only work and think about components.