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

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

IQ>>>>·>Плодить интерфейсы можно и без DI. То что их плодят выкрикивая "DI!" — виновато лишь невежество, а не DI. Бороться надо с невежеством, а не с DI.
IQ>>>>Не спорю, DI всего лишь еще один важный повод.
IQ>>·>Повод для чего?
IQ>>Плодить интерфейсы
·>Так плодит интерфейсы невежество, а не DI. В каком конкретно месте DI требует интерфейсов? Я даже уверен, что большинство IoC-фреймворков вполне могут без них обходиться.

Марк Симан невежество, не я сказал...

IQ>>>>))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.
IQ>>·>Как выяснилось нигде он не плох. Плохи бывают IoC-контейнеры. Вот даже у тебя ambient context — это тот же DI, но один из плохих его видов реализации.
IQ>>Любая, самая идеальная вещь может быть плохой там, где она лишняя.
·>Так отказывайся от ambient context. Он лишний же.

Он собственно появился по одной простой причине — сугубо синтаксическая группировка всех часто используемых сервисов. Его можно смело выкинуть и создавать все нужные сервисы с помощью new.

IQ>>·>В продуманной архитектуре зависимостей нет контекста, есть composition root.
IQ>> Вы думаете local context такой стойкий потому что разработчики ленивые? local context такой стойкий потому, что в него отлично ложатся контексты бизнес операций.
·>Нет, просто невежественные, перечитай топик — много народу тут отметилось которые вообще не знают что такое CI. Вот посмотри на код даже хорошего трудолюбивого студента — код плохой потому что у студента мало опыта и знаний, а не потому что код так лёг.

Имхо если мало знаний нефиг принимать серьезные решения.

IQ>>>>·>В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>>>>Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя.
IQ>>·>Хелпер вообще-то антипаттерн практически, не понимаю почему ты этим хвастаешься.
IQ>>Я не хвастаюсь. Просто раньше из этих хелперов состояли DI сервисы.
·>Так куда эта паутина зависимостей делась? Замели под коврик?

Эта паутина, в данном конкретном случае, никогда никого не интересовала (и до сих пор не интересует). Как например и clr code проекта или как sql сервер парсит запросы и т.д. В этом мире прорва вещей детали которых здесь и сейчас абсолютно не важны.

IQ>>>>Ну и количество интерфейсов уменьшилось на 90%
IQ>>·>Десятый раз повторяю, что интерфейсы для DI+CI не нужны, да и рефакторинг тривиален. Ты их мог и так уменьшить, сохраняя управляемость зависимостей.
IQ>>Я тут запоздало сообразил, что не видел вашего варианта DI. Варианты с DI фреймворками понятны.
·>Вот же: http://rsdn.org/forum/design/6560633.flat#6560633

Автор: ·
Дата: 22.09.16

·>Более разжёвано почитай в том талмуде, который ты показывал, но, похоже, не ещё читал. Задавай вопросы, если что-то непонятно.
·>Спасибо, что ты наконец-то решил почитать что тут пишут.

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

IQ>>Я глянул ваши ответы и не смог найти механизм, который будет в вашем случае создавать и хранить сервисы и инжектить их в клиенты.
·>Зачем хранить сервисы? Сразу создавай и связывай что как надо в composition root. Инжектятся они с помощью CI, десятый раз говорю.

Хотя бы раз назовите фреймворк, который используете. В composition root регистрируются сервисы с клиентами кто их связывает? Что такое CI?

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

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

IQ>>>>·>Плодить интерфейсы можно и без DI. То что их плодят выкрикивая "DI!" — виновато лишь невежество, а не DI. Бороться надо с невежеством, а не с DI.
IQ>>>>Не спорю, DI всего лишь еще один важный повод.
IQ>>·>Повод для чего?
IQ>>Плодить интерфейсы
·>Так плодит интерфейсы невежество, а не DI. В каком конкретно месте DI требует интерфейсов? Я даже уверен, что большинство IoC-фреймворков вполне могут без них обходиться.

Марк Симан невежество, не я сказал...

IQ>>>>))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.
IQ>>·>Как выяснилось нигде он не плох. Плохи бывают IoC-контейнеры. Вот даже у тебя ambient context — это тот же DI, но один из плохих его видов реализации.
IQ>>Любая, самая идеальная вещь может быть плохой там, где она лишняя.
·>Так отказывайся от ambient context. Он лишний же.

Он собственно появился по одной простой причине — сугубо синтаксическая группировка всех часто используемых сервисов. Его можно смело выкинуть и создавать все нужные сервисы с помощью new.

IQ>>·>В продуманной архитектуре зависимостей нет контекста, есть composition root.
IQ>> Вы думаете local context такой стойкий потому что разработчики ленивые? local context такой стойкий потому, что в него отлично ложатся контексты бизнес операций.
·>Нет, просто невежественные, перечитай топик — много народу тут отметилось которые вообще не знают что такое CI. Вот посмотри на код даже хорошего трудолюбивого студента — код плохой потому что у студента мало опыта и знаний, а не потому что код так лёг.

Имхо если мало знаний нефиг принимать серьезные решения.

IQ>>>>·>В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>>>>Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя.
IQ>>·>Хелпер вообще-то антипаттерн практически, не понимаю почему ты этим хвастаешься.
IQ>>Я не хвастаюсь. Просто раньше из этих хелперов состояли DI сервисы.
·>Так куда эта паутина зависимостей делась? Замели под коврик?

Эта паутина, в данном конкретном случае, никогда никого не интересовала (и до сих пор не интересует). Как например и clr code проекта или как sql сервер парсит запросы и т.д. В этом мире прорва вещей детали которых здесь и сейчас абсолютно не важны.

IQ>>>>Ну и количество интерфейсов уменьшилось на 90%
IQ>>·>Десятый раз повторяю, что интерфейсы для DI+CI не нужны, да и рефакторинг тривиален. Ты их мог и так уменьшить, сохраняя управляемость зависимостей.
IQ>>Я тут запоздало сообразил, что не видел вашего варианта DI. Варианты с DI фреймворками понятны.
·>Вот же: http://rsdn.org/forum/design/6560633.flat#6560633

Автор: ·
Дата: 22.09.16

·>Более разжёвано почитай в том талмуде, который ты показывал, но, похоже, не ещё читал. Задавай вопросы, если что-то непонятно.
·>Спасибо, что ты наконец-то решил почитать что тут пишут.

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

IQ>>Я глянул ваши ответы и не смог найти механизм, который будет в вашем случае создавать и хранить сервисы и инжектить их в клиенты.
·>Зачем хранить сервисы? Сразу создавай и связывай что как надо в composition root. Инжектятся они с помощью CI, десятый раз говорю.

Хотя бы раз назовите фреймворк, который используете. В composition root регистрируются сервисы с клиентами кто их связывает? Что такое CI (constructor injection)? Кто/что вам его предоставляет?