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

S>> В смысле? Взял из конструктора:
·>Этот антипаттерн называется Service Locator... Противоположность DI.
Я написал ниже в каких случаях я его использую. От того что что-то называют "антипаттерном" оно не становится автоматически плохим.

S>> Если вам интересен вариант когда провайдер создаётся вручную, то примерно так (псевдокод):
·>Т.е. кода таки больше получилось.
Инициализация DI делается один раз. "Так что кода всё-таки меньше получилось" (и да, "аргумент секретарши" судя по всему идёт через года).

S>> Понятно что этот способ (т.е. через ServiceProvider) используется исключительно в том случае, когда инициализация SomeObject дорогая и сам объект используется он не всегда (я использую его только в контроллере, когда лишь часть экшенов использует его),
·>Вроде это банальный Lazy...
И?

S>> Ну да, сравниете с ручным созданием ServiceProvider — разница в несколько строк. И да, у меня почему-то ни разу не возникало ситуации, когда проблемы с DI были с "рантайм-ошибок и километровых стек-трейсов" — обычно просто сообщение, что требуемый объект не зарегистрирован.
·>А если не использовать фреймворк, то такого рода ошибки будут сразу в IDE подсвечиваться, как ошибки компиляции.
Только в том случае, если вы прямо или косвенно завязаны на конкретные классы. Что, внезапно, тоже "антипаттерн".

S>> И да, этот "весь код" явно ссылается на **реализации** используемых классов, затрудняя его переиспользование (за которое тут так ратуют),
·>Такой код собирает конечное приложение, так называемый Composition Root. Если части приложения нужно переиспользовать, классы можно интегрировать в модуль с подходящими областями видимости и зависимостями, а не кидать всё в глобальный мусорный контейнер.
Когда я вижу как кто-то ударяется в демагогию, у меня возникает стойкое ощущение отсутсвия у него аргументов.

S>> более того, если инициализация чуть сложнее (например нужно получить ConnectionString) — этот код ляжет не один раз в настройку DI, а во все его вызовы. Про всякие мелочи, вроде использование пулов или скоупы даже говорить бессмысленно.
·>Нет, тот же ConnectionString прокинется через ровно такой же DI.
Зачем? Вы просто зададите в DI логику получения зависимости и всё, больше её нигде повторять не нужно.