Ну кому как, я месяц минимум потратил, когда понял что драй мне не подходит.

Вообще, это спорная и сложная тема. Попытки борьбы со сложностью путем создания дополнительных абстракций действительно упрощают многие вещи на высоком, прикладном уровне, но в сущности это все приводит к росту энтропии со страшной скоростью и за это, рано, или поздно придется дорого заплатить.

Володя, статья классная. Чем диаграммы процессов рисовал?

Орыт использования DI на других платформах не подверждает этот тезис.

Я не про DI, я про сложные штуки, о которых выше заговорили:)

Visual Paradigm

thnx

Статью читаю, действительно, хорошо написано.

Спасибо, действительно приятно 🙂

Да, написано просто и понятно.

осталось только объяснить рельсовикам, зачем это все, если можно ничего не конфигурировать, а просто позвать по имени класса )

я кстати до сих пор не нашел ответа на это

я через DI конфигурирую поведение, когда мне нужно через терминал чото там прогнать или отдебажить — вот это кайф

но всё равно непонятно, зачем этим постоянно заниматься

Вообще говоря, если подменить в рельсах механизм автолоада, который будет смотреть в IoC-контейнер, то вот и магия. И ничего не надо делать.
Только контейнер описать.
Но зачем, если 99% компонентов одинаковые и можно написать авторегистратор, который по конвенции сам опишет все "компоненты".  

И чем дальше улучшать, тем больше это будет походить на то, что есть сейчас.

Рельсовики тут не причем и в контексте стандартного MVC (возьми из базы, сделай JSON, отдай клиенту) приложения это все не особо нужно, на самом деле. Вопросы начинаются когда нужно пилить бизнеслогику и резать приложение на слои с границами взаимодействия, а это в общем и целом кухня ортогональная веб фреймворкам.

небольшой оффтоп:
Расскажу как у меня на проекте фронтенд разработчик извлек пользу из DI. Может пригодится.

У нас объемный фронт в виде SPA. Мы сделали графический анализ зависимостей и поняли что основной бандл приложения очень жирный, грузится за раз и исполняется браузером долго (относительно, конечно, но какие-то лишние милисекунды точно жрет). Так вот, мы научились инстанцировать с помощью DI в бандл только те компоненты, которые нужны на конретной странице. Тем самым снизили объем бандла и время на первичную отрисовку.

Для меня ручной менеджмент зависимотей в руби выполняет роль инструмента прозрачности в высоконагруженных компонентах. С автолоадом хз что там в object space наинстанциируеются, а с ручный DI всегда можно отследить цепочку и принять меры.

Другое дело что редко когда овчинка стоит выделки. Нагруженных частей на руби не так много.

удобно, что DI показывает наглядно, сколько класс, модуль в себя вобрал, и ты сразу видишь, что тут походу говнокод если у тебя 15 импортов и большая связность выходит. пример условный. но в той же рельсе мало кто считает количество сторонних модулей и классов, к которым ты обращаешься внутри
а тут у тебя сразу вверху файла алерт красный

каждый комментарий ценен для меня. сегодня ближе к вечеру я обязательно подготовлю резюмированный ответ по основным моментам.