Что такое Dependency Injection (DI)

Что проверяют

Отличаете ли вы принцип от библиотеки. Внедрение зависимостей это про архитектуру, контейнер это инструмент, и подмена одного другим сразу видна.

Как отвечать

Dependency Injection это когда объект не создаёт свои зависимости сам, а получает их снаружи. Чаще всего через конструктор:

public class OrderService(IPaymentGateway payments, ILogger<OrderService> log);

Что это даёт: класс зависит от интерфейса, а не от конкретной реализации. В тесте вместо платёжного шлюза подставляется заглушка, в проде реализация меняется одной строкой регистрации, а по сигнатуре конструктора видно, от чего класс вообще зависит.

Способы внедрения: конструктор (по умолчанию, зависимость обязательна), свойство (для необязательных), метод (когда нужна ровно в одном вызове).

Времена жизни в контейнере, если речь про ASP.NET Core:

• Transient: новый экземпляр на каждый запрос к контейнеру;
• Scoped: один на HTTP-запрос;
• Singleton: один на приложение.

Где спотыкаются

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

Регистрируют DbContext синглтоном и получают гонки: он не потокобезопасен и должен быть Scoped.

Захватывают Scoped внутри Singleton и живут с устаревшей зависимостью весь процесс.

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

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