Как использовать Dependency Injection, а не Service Locator

Question

Я слышу, как люди говорят, что вам не следует использовать сервисный локатор для инъекции зависимостей. Итак, как именно вы вводите зависимости, не полагаясь на локатор службы? Я хочу опробовать контейнеры IoC, но не хочу использовать анти-шаблон.

Должны ли вы просто все настроить, чтобы было одно место, где все классы всегда имеют цепочку зависимостей от самых глубоких классов? (если я / это вообще имеет смысл)

Я не прав, если весь ваш код завален зависимостями от выбранного контейнера IoC, не так ли?

Так, где вы «используете» свой контейнер (для рексолвинга)? И как вы получаете это, чтобы решить все, так глубоко, как идет ваш код? Является ли частью проектирования все правильно, используя интерфейсы через каждый уровень вплоть до переднего уровня?

Или я просто упускаю точку?

Позвольте мне напомнить вам, что я просто не хочу впадать в анти-паттерн, и мне нужны некоторые советы / рекомендации.

Answer 1

Если вы просто все настроите так есть одно место, где все классы всегда иметь цепочку зависимостей к самые глубокие занятия? (если я / что делает смысл вообще)

Да, это называется составной корень вашего приложения, и именно здесь вы конфигурируете свой контейнер IoC и разрешаете свой корневой тип.

Неправильно иметь весь ваш код завален зависимостями от IoC контейнер выбора, это?

Правильно, лучше не передавать ссылки на ваш контейнер IoC вокруг ваших типов, поскольку это сделает их менее пригодными для повторного использования, и связывать типы с концепцией контейнеров IoC в целом.

Так где же вы "используете" свой контейнер (для рексолвинга)? И как сделать Вы получаете это, чтобы решить все, как как глубоко твой код идет? Это часть проектировать все правильно используя интерфейсы через каждый слой до переднего слоя?

Вы будете использовать свой контейнер в корневом каталоге композиции и в любом месте своего кода, для которого необходимо создавать экземпляры типов (т. Е. Из фабричных типов) через контейнер (обычно для поддержки цепочки зависимостей).

Многие контейнеры IoC могут генерировать эти типы фабрики для вас, поэтому вам нужно только передать, например, IMyFactory в качестве зависимости или, в случае некоторого контейнера IoC, Func<IMyService>. Это означает, что вам не нужно создавать фабричные типы, которые зависят от вашего контейнера IoC.

С точки зрения использования интерфейсов, принцип инверсии зависимостей гласит, что вы должны зависеть от абстракций, а не от конкреций, поэтому вам нужно будет учитывать ваш код с учетом этой концепции, если вы хотите внедрить внедрение зависимостей.