Здравствуйте, IQuerist, Вы писали:
IQ>>>·>Плодить интерфейсы можно и без DI. То что их плодят выкрикивая "DI!" — виновато лишь невежество, а не DI. Бороться надо с невежеством, а не с DI.
IQ>>>Не спорю, DI всего лишь еще один важный повод.
IQ>·>Повод для чего?
IQ>Плодить интерфейсы
Так плодит интерфейсы невежество, а не DI. В каком конкретно месте DI требует интерфейсов? Я даже уверен, что большинство IoC-фреймворков вполне могут без них обходиться.
IQ>>>))) пост не о том, где DI хорош (кстати это имхо был бы крайне полезный пост), а о том, где он плох.
IQ>·>Как выяснилось нигде он не плох. Плохи бывают IoC-контейнеры. Вот даже у тебя ambient context — это тот же DI, но один из плохих его видов реализации.
IQ>Любая, самая идеальная вещь может быть плохой там, где она лишняя.
Так отказывайся от ambient context. Он лишний же.
IQ>>>·>По-моему опыту так же. Что такое "отхреначивать наивный DI" ты так и не прояснил. Как я понял — ты заменял CI на глобальные переменные.
IQ>>>Ага на 2-3 глобальных сервиса. Ну глобальные они только формально, на самом деле они в local context, как собственно и сервисы DI.
IQ>·>Изменяемые данные в статических полях есть? Значит глобальные и формально, и на самом деле.
IQ>В статических полях исключительно stateless сервисы. Изменяемые данные в local context. Это или thread contect или httpcontext.
TLS это то же
статическое поле, по сути это статическая мапа с локами, где где ключом является currentThreadId. Глобальная переменная, перенесённая под реалии многопоточного программирования. httpcontext.current это тоже TLS.
IQ>·>В продуманной архитектуре зависимостей нет контекста, есть composition root.
IQ>
Вы думаете local context такой стойкий потому что разработчики ленивые? local context такой стойкий потому, что в него отлично ложатся контексты бизнес операций.
Нет, просто невежественные, перечитай топик — много народу тут отметилось которые вообще не знают что такое CI. Вот посмотри на код даже хорошего трудолюбивого студента — код плохой потому что у студента мало опыта и знаний, а не потому что код так лёг.
IQ>>>·>В чём именно было улучшение-то от этого твоего отхреначивания?
IQ>>>Хелперы стали хелперами без паутины зависимостей, которая в рамках конкретно этих проектов была излишняя.
IQ>·>Хелпер вообще-то антипаттерн практически, не понимаю почему ты этим хвастаешься.
IQ>Я не хвастаюсь. Просто раньше из этих хелперов состояли DI сервисы.
Так куда эта паутина зависимостей делась? Замели под коврик?
Зашли в тёмный подвал, включили свет — ух сколько грязи и паутины, давайте лучше лампочку разобьём, чтобы этого ничего не было видно, ну и напишем пост "О наивном освещении в подвале".
IQ>>>Ну и количество интерфейсов уменьшилось на 90%
IQ>·>Десятый раз повторяю, что интерфейсы для DI+CI не нужны, да и рефакторинг тривиален. Ты их мог и так уменьшить, сохраняя управляемость зависимостей.
IQ>Я тут запоздало сообразил, что не видел вашего варианта DI. Варианты с DI фреймворками понятны.
Вот же:
http://rsdn.org/forum/design/6560633.flat#6560633Автор: ·
Дата: 22.09.16
Более разжёвано почитай в том талмуде, который ты показывал, но, похоже, не ещё читал. Задавай вопросы, если что-то непонятно.
Спасибо, что ты наконец-то решил почитать что тут пишут.
IQ>Я глянул ваши ответы и не смог найти механизм, который будет в вашем случае создавать и хранить сервисы и инжектить их в клиенты.
Зачем хранить сервисы? Сразу создавай и связывай что как надо в composition root. Инжектятся они с помощью CI, десятый раз говорю.
IQ> Ладно, оставим это все на совести адептов DI. Собсна цель моего поста не в том, чтобы запрещать им ковырять в носу.
Ты не отмахивайся, а читай и борись с невежеством, а не с DI.
