Зачем нужен Service Locator?

Question

[Amir228]

Вобще зачем такой не удобный и не лучший способ внедрение зависимостей через GetService()? Не легче ли внедрение делать через конструкторы?

Answer 1

[Сергей Соловьев]

Случаев использования много. В некоторых без него не обойтись.
Например:
- Зависимость необязательна
- Есть множество реализаций, а не 1
- Отложенное создание

Если не хочешь использовать - не используй

Comments

[MVV]

В перечисленных вами случаях обойтись-то как раз можно:
- используйте тип Зависимость? вместо Зависимость
- используйте тип IEnumerable<Зависимость> вместо Зависимость и выбирайте нужную
- используйте IOptionsSnapshot<Зависимость>: объект зависимости будет создаваться в момент обращения и жить только в рамках ограниченной области (т.е., по-простому - во время обработки одного запроса).

Но места, где без Service Locator не обойтись, таки есть: либо они лежат вне области применимости фреймворков, либо (зачастую) там, где не получается что-то сделать чисто через конструктор и требуется передать делегат.

Но, таки да, теоретики говорят, что Dependency Injection - хорошо, Service Locator - плохо. Правда, потом может случиться, как с "четыре" и "две" - вместо "плохо" станет "лучше". К примеру, на моей памяти с комментариями так и случилось.

Answer 2

[MVV]

Не легче ли внедрение делать через конструкторы?

А вы не задумывались над тем, кто и как будет разрешать зависимости для конструкторов?
В нынешнем ASP.NET Core этим занимются каркасы приложений ("фрейворки", от английского framework). И делают они это как раз через контейнер сервисов (либо напрямую через GetService, либо через ActvatorUtilities).
Но есть области в ASP.NET Core , которые фремворками не закрываются - наример, в конвейере обработчиков запроса (middleware), там где требуется делегат типа RequestDelegate. И там без прямого обращения к контейнеру сервисов не обойтись.