> Many a Java developer think that you need a big complicated framework to pass dependencies into your modules, instead of having your modules fetch them for themselves.
Not sure what you mean by "module" here, but DI means that the dependencies are defined externally to the actual business logic, which kinda contradicts this "fetch them for themselves".
I think the problem with Spring is that it has too many features, too many different ways to do the same thing, too much configurability. Historically, Spring jumped on most hypes, tried to basically support everything. We ended up with this complexity monster, but this also made it popular. Spring is the Oracle DB of the backend development in the sense that you won't ever get fired for choosing it, it's the safe choice which will support in some way everything you might need to do.
In the context of Java, by "module", I really mean "class" or "object".
> but DI means that the dependencies are defined externally to the actual business logic, which kinda contradicts this "fetch them for themselves".
Yes, that is what I am saying, DI is an alternative to patterns like the singleton class.
For example if you have a singleton for a database connection, and a bunch of services that use it.
The services have a direct reference to the singleton, they "fetch the db connection for themselves".
Compared to DI, a singleton makes it more difficult to mock the connection for tests, also running tests in parallel is more difficult.
If you get a requirement to make the app multi-tenant, refactoring the application to talk to multiple databases is more difficult.
I thought that you were hinting that DI can be done (esp. on a smaller scale) often manually without any complex container magic.
Like in a smaller app, construct all your service instances in the main method while passing the dependencies into constructors and voilà - you have a DI based application without a container / any framework.
> I thought that you were hinting that DI can be done (esp. on a smaller scale) often manually without any complex container magic.
I also agree with this, and at any scale.
Actually I think the larger scale the codebase, the more it would benefit from manual DI, obviously at that point, the wiring code grows and you would probably break it down into multiple methods.
Not sure what you mean by "module" here, but DI means that the dependencies are defined externally to the actual business logic, which kinda contradicts this "fetch them for themselves".
I think the problem with Spring is that it has too many features, too many different ways to do the same thing, too much configurability. Historically, Spring jumped on most hypes, tried to basically support everything. We ended up with this complexity monster, but this also made it popular. Spring is the Oracle DB of the backend development in the sense that you won't ever get fired for choosing it, it's the safe choice which will support in some way everything you might need to do.