Yeah, to startup the container and manage the object graph, sure. But not to directly instantiate the objects like you've given in your example!
The whole point behind DI is to decouple objects, any IoC container worth it's salt gets started and works it out for you. You shouldn't need to resolve the individual object.
Another poster noted this is known as composition root, a good explanation can be found here:
Comments
Yeah, to startup the container and manage the object graph, sure. But not to directly instantiate the objects like you've given in your example!
The whole point behind DI is to decouple objects, any IoC container worth it's salt gets started and works it out for you. You shouldn't need to resolve the individual object.
Another poster noted this is known as composition root, a good explanation can be found here:
http://blog.ploeh.dk/2011/07/28/CompositionRoot/
Note the following:
"A DI Container should only be referenced from the Composition Root. All other modules should have no reference to the container."
Words to live by :-)
True indeed, however, the point remains:
IOC is resolving an instance with it's dependencies.
How you do that is irrelevant.
The point is that the action of resolving dependencies is NOT dependency injection.
If you're writing an IOC container, call it an IOC container.
Excuse me, but the IoC Container is doing the injecting. That's the whole point.