I have recently worked on a Python project where we did dependency injection heavily (because we must in order for the app to be testable), but we didn't use any framework. At times it was a little tedious to wire up all the dependencies manually, but overall it worked great.
When an object had to be created in multiple places, we simply had a function (sometimes a class method of that object) to create a production instance. This function was called whenever we needed that object.
In the tests, we did the same thing: if multiple times we needed to create a 'test-version' of an object (i.e., a real instance backed by mock objects), we had a function to create this 'test-version' of a class, to be used in tests.
As I said, generally this worked fine.
I am now entering a new Java project, and we are deciding whether to use a DI framework, or do DI manually (like in the previous project).
Please explain how working with a DI framework will be different, and in what manners it is better or worse than manual 'vanilla' dependency injection.
Edit: I would also like to add to the question: have you witnessed any 'professional level' project that does DI manually, without a framework?
Best Answer
The key of DI containers is the abstraction. DI containers abstract this concern for you. As you may guess, it has a noticeable impact on the code, often translated into a fewer number of constructors, setters, factories and builders. In consequence, they make your code more loosely coupled (due to the underlying IoC), cleaner and simpler.
Backgrounds
Years ago, DI required us to write config files (declarative programming). It was fantastic to see the number of LOC diminishing substantially, but while the LOCSs decreased, the number of config files slightly increased. For medium or small projects it was not a problem at all, but for larger projects having the DI scattered between code and several files became a pain in the ... Nonetheless, the main problem was the paradigm itself. It was quite inflexible because the descriptors left little space for customizations.
The paradigm shifted progressively towards to convention over configuration, which trades config files for annotations or attributes. It keeps our code cleaner and simpler while providing us with the flexibility that XML could not. Some DI contianers are programable so the DI graph can change in runtime.
Now, without setters, constructors and XML the application is more than clean. Is also magic.
On the down side...
Convention over configuration makes the abstraction so heavy that you barely know how it works. Sometimes seems magic and here comes one more drawback. Once is working, many developers don't care about how it works.
This is a handicap for those who learnt DI with DI containers. They don't fully understand the relevance of the design patterns, the good practices and the principles that were abstracted by the container. I have asked developers if they were familiarised with DI and its advantages and they answered: -Yes, I have used Spring IoC-. (What the hell does it mean?!?)
One can agree or not with each of these "drawbacks". In my humble opinion, it's a must to know what's going on in your project. Otherwise, we don't have a full understanding of it. Also is to know what DI is for and to have a notion of how to implement it is a plus to consider.
On the plus side...
One word productivity. Frameworks let us focus on what really matters. The application's business.
Despite the commented shortcomings, for many of us (which job is conditioned by deadlines and costs), these tools are an invaluable resource. In my opinion, this should be the main argument in favour of implementing a DI containers.
Testing
Whether we implement pure DI or containers, testing is not going to be a problem. Quite the opposite. The same containers often provide us with the mocks for unit testing out of the box. Along the years I have used my tests as thermometers. They tell me if I have relied heavily on the containers facilities. I say this because the containers I'm used can initialize private attributes without setters or constructors.
Sounds tempting right? Be careful! Don't fall into the trap!
Suggestions
If you decide to implement containers, I strongly suggest sticking with the good practices. Keep implementing constructors, setters and interfaces. Enforce the framework/container to use them. It will make easier possible migrations to another framework or to remove the actual one. It can reduce significantly the dependency on the container what ease the testing too.
Regarding this practices:
When to use DI containers
My answer is going to be biased by own experience which is mainly in favour of DI containers (as I commented, I'm heavily focused on productivity, so I have never had the need of pure DI. Quite the opposite).
I think you will find interesting Mark Seeman's article about this subject, which also answers the question how to implement pure DI?.
Finally, if we were speaking of Java, I would consider first taking a look to the JSR330 - Dependency Injection.
Summarising
Benefits:
Drawbacks:
Differences with pure DI: