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

S> В смысле? Взял из конструктора:
Этот антипаттерн называется Service Locator... Противоположность DI.

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

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

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

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

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

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

S> В смысле? Взял из конструктора:
Этот антипаттерн называется Service Locator... Противоположность DI.

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

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

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

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

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