Здравствуйте, Tom, Вы писали:

Tom>Понимаю сейчас что польются литры говна на меня от тех кто не осилил и не понял смысла DI но попробую ответить.
Tom>Лично для себя сделал простой вывод, DI НЕ требуется только для объектов в которых нет логики, т.е. POCO.

Звучит эпически, а как быть со stateless объектами в которых одна логика и нет состояния? Для чего им DI, если потенциальное время их жизни — от старта системы до самого ее финиша?

Tom>Всё остальное — DI. Причин тут несколько и все они достаточно очевидны и разжёваны не мной а в тьме видео описывающих какие именно проблемы решает DI но я ещё раз ох опишу.

Tom>1. Когда говорят про использование DI то в 99% случаев DI используют вместе с контейнером. А смысл контейнера не только в предоставлении зависимостей а в управлении временем жизни объекта. Делегирование управления жизни обьекта контейнеру — одна из самых принципиальных вещей.

Забавно ))) вот например время жизни db entity определяется оно как правило контекстом внутри одного метода от загрузки из БД до сохранения в БД. Вот например есть ворох статических хелперных методов не имеющих состояния. Вот например есть целые сервисы, зависимость от которых и жизни которых определяется контекстом бизнес операции т.к. сильно зависит от бизнес логики...

Мне кажется или ваша позиция больше связана с вопросами веры, чем с вопросами разработки ПО?

Tom>2. Использование DI позволяет тебе чётко определять все зависимости объекта, зависимости становятся явными и получает их обьект обычно в конструкторе. Иными словами мне НЕ нужно лазить по коду объекта что бы понять а от чего ещё он зависит. Достаточно глянуть в конструктор и всё становится понятным.

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

Tom>3. При тотальном использовании DI во всём проекте во всём проекте используется один и тот же стандартных подход. Такой код читать просто и понятно. А вот обратный случай когда вот тут вот мы сделаем new, а вот там вот вызовем статический метод а вот это вот мы заинжектим потому что оно — это сервис (а что такое сервис никто не знает). Это точно бред.

А вы не задумывались откуда может взяться понимание, что есть сервис, а что нет на старте проекта? А ведь DI религиозные фанатики начинают использовать в самом начале. Ах да... Tom — "Всё остальное — DI." Т.е. вообще все прямо с самого старта и есть цель для DI... Colonoscopy Injection детектед В общем мой пост как раз про это.

Tom>В целом у автора пока просто мало опыта использование DI и DI для него новая концепция при переходе к которой абсолютно естественно возникает куча вопросов и нормальное отторжение. Так у всех, это нормально.

У меня полно опыта в области DI. Я отхреначивал DI нафиг уже в трех проектах потому как с ним архитектура типа big ball of mud становиться абсолютно неподдерживаемой.

Здравствуйте, Tom, Вы писали:

Tom>Понимаю сейчас что польются литры говна на меня от тех кто не осилил и не понял смысла DI но попробую ответить.
Tom>Лично для себя сделал простой вывод, DI НЕ требуется только для объектов в которых нет логики, т.е. POCO.

Звучит эпически, а как быть со stateless объектами в которых одна логика и нет состояния? Для чего им DI, если потенциальное время их жизни — от старта системы до самого ее финиша?

Tom>Всё остальное — DI. Причин тут несколько и все они достаточно очевидны и разжёваны не мной а в тьме видео описывающих какие именно проблемы решает DI но я ещё раз ох опишу.

Tom>1. Когда говорят про использование DI то в 99% случаев DI используют вместе с контейнером. А смысл контейнера не только в предоставлении зависимостей а в управлении временем жизни объекта. Делегирование управления жизни обьекта контейнеру — одна из самых принципиальных вещей.

Забавно ))) вот например есть ворох статических хелперных методов не имеющих состояния. Вот например есть целые сервисы, зависимость от которых и жизни которых определяется контекстом бизнес операции т.к. сильно зависит от бизнес логики...

Мне кажется или ваша позиция больше связана с вопросами веры, чем с вопросами разработки ПО?

Tom>2. Использование DI позволяет тебе чётко определять все зависимости объекта, зависимости становятся явными и получает их обьект обычно в конструкторе. Иными словами мне НЕ нужно лазить по коду объекта что бы понять а от чего ещё он зависит. Достаточно глянуть в конструктор и всё становится понятным.

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

Tom>3. При тотальном использовании DI во всём проекте во всём проекте используется один и тот же стандартных подход. Такой код читать просто и понятно. А вот обратный случай когда вот тут вот мы сделаем new, а вот там вот вызовем статический метод а вот это вот мы заинжектим потому что оно — это сервис (а что такое сервис никто не знает). Это точно бред.

А вы не задумывались откуда может взяться понимание, что есть сервис, а что нет на старте проекта? А ведь DI религиозные фанатики начинают использовать в самом начале. Ах да... Tom — "Всё остальное — DI." Т.е. вообще все прямо с самого старта и есть цель для DI... Colonoscopy Injection детектед В общем мой пост как раз про это.

Tom>В целом у автора пока просто мало опыта использование DI и DI для него новая концепция при переходе к которой абсолютно естественно возникает куча вопросов и нормальное отторжение. Так у всех, это нормально.

У меня полно опыта в области DI. Я отхреначивал DI нафиг уже в трех проектах потому как с ним архитектура типа big ball of mud становиться абсолютно неподдерживаемой.