Lately there has been very much emphasis on DI *frameworks*, even so that the DI *pattern* is being forgotten. DI's principles as [summarized by J. B. Rainsberger][1]:
> It's simple: make dependencies explicit by requiring collaborators as
> parameters in the constructor. Repeat until you've pushed all decisions
> about which objects to create into the entry point. Of course, this only
> applies to Services (in the DDD sense). Done.
As you've noticed, there is not much difference between configuring the dependencies manually vs. using a framework. With constructor injection, as shown below, your code example would have even less boilerplate and the compiler would force you to provide all required dependencies (and your IDE will probably type them for you).
SawMill sawMill = new SawMill(new HandSaw());
sawMill.run();
A DI framework can reduce the boilerplate of creating factories and wiring the objects together, but at the same time it can also make it harder to find out that where each dependency is coming from - the DI framework's configuration is one more layer of abstraction to dig through, and your IDE might not be able to tell you where a particular constructor is being called from.
An indirect disadvantage of DI frameworks is that they can make wiring the dependencies *too easy*. When you can't anymore [feel pain][2] from having lots of dependencies, you may just keep on adding more dependencies instead of rethinking the design of the application to reduce the coupling between the classes. Wiring the dependencies manually - especially in test code - makes it easier to notice when you have too many dependencies as the test setup becomes longer and it becomes harder to write unit tests.
Some advantages of DI frameworks come from their support of advanced features such as AOP (for example Spring's @Transactional), scoping (though many times [scoping with plain code][3] will be enough) and pluggability (if a plugin framework is really needed).
Recently I made an experiment of manual DI vs. framework-based DI. The progress and results are shown as screencasts in [Let's Code Dimdwarf episodes 42 through 47][4]. The project in question had a [Guice][5]-based plugin system for creating [actors][6], which I then rewrote using manual DI, without Guice. The result was a much simpler and clearer implementation, and only a little bit more boilerplate.
**Synopsis:** First try using just manual DI (preferably constructor injection). If there becomes lots of boilerplate, try to rethink the design to reduce the dependencies. Use a DI framework if some of its features provide value for you.
[1]:
[To see links please register here]
[2]:
[To see links please register here]
[3]:
[To see links please register here]
[4]:
[To see links please register here]
[5]:
[To see links please register here]
[6]:
[To see links please register here]
]
