what's the point of Dependency Injection Frameworks?

Question

I am sure that I am somewhat lost in this area... my understanding is that Dependency Injection means initializing something that is required by a class..so for instance. If my controller is going to need a service and I want to be able to test it then I should define two Constructor methods for it... so, my question is... why do people use Frameworks to achieve this?? Im lost

public class CompaniesController : Controller
    { 
        private ICompaniesService _service;

        public CompaniesController()
        {
            _service = new CompaniesService();
        }

        public CompaniesController(ICompaniesService service)
        {
            _service = service;
        }

Answer 1

People don't use a Dependency Injection Framework to generate the code that you provided in your example. That's still the work of the developer.

The Dependency Injection Framework is used when somebody calls the constructor. The Framework will Inject the concrete implementation of the ICompaniesService rather than the developer explicitly calling the constructor.

While it is a specific product, the nInject Homepage actually has some really good examples.

Answer 2

A major reason is to better support unit testing and mocking out objects to create controlled tests.

By not specifying the implementation inside the class, you can 'inject' an implementation at run time. (In your example, the ICompaniesService interface).

At runtime, using an inversion of control/dependency injection container such as StructureMap, Unity or Castle Windsor, you can say "hey, anytime someone wants an instance of ICompaniesService give them a new CompaniesService object".

To unit test this class, you can mock our a ICompaniesService and supply it yourself to the constructor. This allows you to setup controlled methods on the mock object. If you couldn't do this, your unit tests for CompaniesController would be limited to using only the one implementation of your companies service, which could hit a live database etc, making your unit tests both slow and inconsistent.

Answer 3

From Wikipedia:

Without the concept of dependency injection, a consumer who needs a particular service "ICompaniesService" in order to accomplish a certain task would be responsible for handling the life-cycle (instantiating, opening and closing streams, disposing, etc.) of that service. Using the concept of dependency injection, however, the life-cycle of a service is handled by a dependency provider/framework (typically a container) rather than the consumer. The consumer would thus only need a reference to an implementation of the service "ICompaniesService" that it needed in order to accomplish the necessary task.

Read this one too:

What is dependency injection?

Answer 4

People use Dependency Injection frameworks because otherwise you have to write a metric ton of boring, repetitive factory classes (if using dependency injection, that is).

It can be done, it's just very, very annoying.

Answer 5

I think your understanding is only partly correct. Dependency Injection is "injecting" a dependency of a component into it. Its a more specific form of inversion of control. During this process some dependencies can also be initialized before injecting.

With DI, the onus of looking up the dependency is not on the component (as in ServiceLoacator pattern) but upto the container in which the component is running. The pattern has following advantages:

• Dependency lookup code can be eliminated from the component.
• Some frameworks providing auto-wiring, injecting saving you from manually creating your component hierarchies (Answers one of your questions)
• Allows you to interchange implementations of your dependencies. (without using Factories)
• Testing (replacing dependencies with mock implementations)

In your code example, a dependency can be injected by a DI container at runtime via the second constructor. Other forms of injections are also possible (depending on the DI container). e.g. Field injection, setter injection, etc.

There's a good article by martin fowler who coined the DI term

Answer 6

You dont have to have a DI framework, but at some point in your codebase a concrete implementation is going to need to be instantiated and injected into your constructors/properties. It can get very messy if you dont have a DI framework, I recommend looking at Castle Windsor although as mentioned there are others that will perform the same functionality. Or if you could role your own....:)