Нет не серьезно. Забыл смайл поставить.

Любое ИМХО на чем то основано). Я не один такой, холиваров полно на эту тему.

И еще раз, чтобы была понятна моя позиция. Концепция DI хороша для унификаций. С этим надеюсь спорить не станем? Но далеко не все проекты в ней нуждаются. Яркое подтверждение - наш последний батл. Я выполнил ТЗ (кстати, тобой разработанное) за 2 недели, твое приложение не работает до сих пор. Все потому, что я именно делал ТЗ, а ты пытался написать универсальный фремворк. Это к вопросу скорости разработки. Второе, что успели выяснить, - прозрачность. DI, это на сегодняшний день - абстракция запредельная. Найти где что чем управляется и что в конкретный момент отрабатывает, та еще гемрроидальная язва задача. А если учесть то, что конфиги у всех разные и в ядре невидимы, полный адъ и израиль. Дальше трассировка. В случае, когда аргументами передается объект, там такое намешано, что без бутылки (а то и четверти), не разобраться.

Плюсы есть конечно, то же Юнит-тестирование. Хотя можно и без DI все организовать, но так вроде вам привычнее. Ну и естественно унификация. Что в отрыве от фреймворка теряет смысл.

Так что да, ИМХО, но не просто потому, что мне не нравится. А вполне обдуманное и выстраданное. А просто схватить верхушку, запендюрить в проект и радоваться, что я крут... Ну это оставим вам, ненаевшимся еще кодов)))

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

сам решай.

_____________
Трус не играет в хокей

Твой комментарий бесмысленный.

_____________
Мой блог

В точку, как всегда!

_____________
Не тот велик, кто не падал, а тот кто падал и поднимался.

Зависит от реализации, напримерер Symfony DI действительно сложный, так как много на себе берет. Я конечно согласен что DI не всегда нужен, но без него вряд ли можно выстроить каноничную ООП архитектуру (очень важный момент, именно с использование DI становится нужным такой инструмент как интерфейс)

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Думаю твой комментарий безсмысленее моего. Потому как мой комментарий говорит что программирование надо ли не надо ТС и об этом может решить только сам ТС. А твой же комментарий предлагает ТС послушать мнение других которое может сыграть с ним злую шутку как посоветовав согласится так и посоветовав отказаться от разных идей.

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

_____________
Трус не играет в хокей

Вот что приходит на ум от таких заявлений)))

Ну раз нельзя выстроить каноническую, то и нафиг тогда вообще выстраивать))) И где те каноны? Где они были до изобретения DI? Значит до того ООП и не ООП вовсе было? И самое главное - где они будут, когда DI объявят ересью, как сейчас объявили наследование?

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

_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.

Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.

Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.

Отчасти да, в большинстве случаев что называют ООП, по факту является процедуркой на классах. Но вернемся к внедрению зависимостей, то что оно вышло в тренд не значит, что до этого его не было. Раньше внедрение зависимостей было ручное, то есть, есть объект А, ты ему в сеттер передаешь объект Б, внедрение зависимостей, только ручное.

Ну и конечно же, я не рекомендую использовать DI в проекте, если проект не собирается разрабатываться в ООП стили. Процедурка и DI вещи тупо не совместимые.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

MVC это архитектура деления приложения на слои, DI это технология для обсуживания объектов зависимостями. В итоге, вопрос задан не правильно.

Razzwan, DI нужен только тогда когда он тебе действительно нужен.

_____________
Люди, имеющие низкий уровень квалификации, делают ошибочные выводы, принимают неудачные решения и при этом неспособны осознавать свои ошибки в силу низкого уровня своей квалификации

Я теперь понял свою ошибку в одном из своих предыдущих ответов. Но все равно спасибо.


_____________
Youtube канал WebDeveloper->Run()
Сайт для души
Gitter