The original value proposition of DI (dependency inversion) was that you could write your tax logic and unit-test it without the code knowing that it's talking to MySQL. Injecting your dependencies into your constructor makes dependency inversion possible.
That messaging has somehow become smeared across dependency injection, frameworks, classpath scanning, autowiring, reflection, annotations etc.
20 years ago, DI meant that your TaxCalculator didn't know about your database.
Today, DI means that your TaxCalculator still knows about your database, but now it knows about Spring too.
The original value proposition of DI (dependency inversion) was that you could write your tax logic and unit-test it without the code knowing that it's talking to MySQL. Injecting your dependencies into your constructor makes dependency inversion possible.
That messaging has somehow become smeared across dependency injection, frameworks, classpath scanning, autowiring, reflection, annotations etc.
20 years ago, DI meant that your TaxCalculator didn't know about your database.
Today, DI means that your TaxCalculator still knows about your database, but now it knows about Spring too.