Как работает внедрение зависимостей (dependency injection) в .NET?

Question

Accepted Answer

**Dependency Injection (DI)** встроен в современный .NET — фреймворк включает DI-контейнер, который автоматически конструирует классы и **внедряет их зависимости**. Вы регистрируете сервисы (сопоставляя интерфейсы с реализациями), а контейнер их разрешает, позволяя создавать слабо связанный и тестируемый код. Это основа ASP.NET Core. ## Регистрация сервисов ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` Вы регистрируете каждое сопоставление сервиса, связывая **интерфейс с реализацией** и указывая время жизни. Тогда любой класс, зависящий от интерфейса, получает зарегистрированную реализацию. ## Внедрение через конструктор (стандартный паттерн) ```csharp public class UserService { private readonly IUserRepository _repo; private readonly IEmailSender _email; // dependencies are declared in the constructor — the container INJECTS them automatically public UserService(IUserRepository repo, IEmailSender email) { _repo = repo; _email = email; } } // you never `new UserService(...)` manually — the container builds it, resolving the chain ``` Зависимости объявляются как параметры конструктора (с типом интерфейса); контейнер конструирует класс и внедряет зарегистрированные реализации, автоматически разрешая весь граф зависимостей. ## Времена жизни сервисов (важно выбрать правильно) ```text Singleton → ONE instance for the entire app lifetime (shared; must be thread-safe) Scoped → one instance PER request (the common default for web — e.g. DbContext) Transient → a NEW instance every time it's requested (lightweight, stateless services) → Choosing wrong (e.g. a singleton capturing a scoped DbContext) causes subtle bugs. ``` ## Преимущества: слабая связанность и тестируемость ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## Почему это важно Внедрение зависимостей — основа современного .NET — оно **встроено в фреймворк** и является основой ASP.NET Core, поэтому его понимание необходимо для любой разработки современного приложения на C#. Встроенный в фреймворк DI-контейнер автоматически конструирует классы и внедряет их зависимости (разрешая весь граф зависимостей), поэтому вы регистрируете сервисы и позволяете контейнеру всё связать воедино, вместо того чтобы вручную инстанцировать зависимости. Основные преимущества значительны и являются центральной причиной, почему DI подчёркивается: **слабая связанность** (зависимость от интерфейсов, а не конкретных классов, поэтому реализации можно менять) и особенно **тестируемость** (внедрение mock-реализаций в тестах вместо реальных зависимостей, таких как базы данных или сервисы email — делая полное модульное тестирование практическим). Основополагающее значение имеют: регистрация сервисов (сопоставление интерфейсов с реализациями), внедрение через конструктор (стандартный паттерн) и — что важно — **времена жизни сервисов** (`Singleton`, `Scoped`, `Transient`). Выбор неправильного времени жизни вызывает тонкие, сложно отлаживаемые ошибки (например, singleton, держащий scoped `DbContext`, или проблемы с потокобезопасностью у общих singleton'ов), поэтому понимание того, когда каждое время жизни применяется (Scoped для каждого запроса для таких вещей, как DbContext, Singleton для общих stateless-сервисов, Transient для лёгких) — критично. Поскольку DI встроен в .NET, составляет основу архитектуры ASP.NET Core и является ключом к написанию слабо связанного и тестируемого кода, его освоение — контейнер, внедрение через конструктор, проектирование на основе интерфейсов и особенно времена жизни сервисов — важно как часто применяемое знание для построения поддерживаемых и тестируемых современных приложений на C#, и это частая тема на собеседованиях.