Не свежо.
Spring DI не единственный способ реализации DI. Я на мелких проектах и без Spring просто пишу отдельный класс, который реализует DI.
Управление зависимостями / IoC, это не такая простая проблема, как кажется на первый взгляд. Ещё задолго до Spring она решалась в JEE через Service Locator. Контейнер это отдельный слой, который реализует инфраструктуру, убирая её из классов, решающих задачи более близкие к предметной области.

Так что уточни конкретно своё мнение.
Spring DI бесполезен - есть другие легековесные движки?
DI бесполезен - есть Service Locator?
IoC бесполезен - это нормально, когда dependency management инфраструктура разамазана по всем классам? Ведь каждый класс знает какие у него зависимости. Так?

MasterZivИли еще можно так:
Не окладывай на завтра!
Реши проблемы, которых у тебя никогда не будет, прямо сейчас! Ведь завтра их просто может не быть!
http://www.rsdn.ru/forum/humour/1600906.1

Сначала ты не знаешь об проблеме и тебе просто говорят - используй Spring.
Потом ты знаешь о проблеме и знаешь когда использовать Spring, а когда не нужно.

http://martinfowler.com/articles/injection.html
В выводах и заключнении есть ответ.

MasterZivDI бесполезен - есть Service Locator?
DI и IoC бесполезны и не нужны в 90% случаев.
Ну, если прогать игры под андроид, то возможно.

MasterZivДа, нормально. Зависимости — это вообще нормально. От них вообще очень редко когда нужно избавляться.
Зависимости имеют противное свойство усиливать связи. Усиление связей делает болезненым какие-либо изменения кода. Изменения кода нужны, так как требования к проекту меняются. Изменение трабований к проекту можно принять за аксиому.

MasterZivА если что — можно, и будет легче, просто пересобрать программу.

Рефакторинг это теперь "просто пересобрать"?

MasterZivЕсли нужно, можно и просто ее переписать. Все равно будет проще, чем DI.
Не будет.

maytonBlazkowicz, мне кажется идея DI не в том чтобы декларировать их отдельно от кода
а в том чтобы максимально ослабить эти самые DI и перенести их объявления
из кода в конфигурацию.
Няня, я у них поел.
"ослабить DI"?
"идея не в том чтобы декларировать отдельно от кода,
а в том чтобы перенести объявления из кода в конфигурацию"
Это не одно и то же?

maytonНет не одно и тоже. Есть два измерения. Первое ось разработки DI программное/конфигурируемое.
И вторая ось измерений это связность. Слабая/сильная. Я так думаю.
Понятно. Фаулер о том же пишет. Просто формулировка у тебя странная. Ослабляют связность, а не DI.