Какие знаешь области времени жизни контейнеров?

Области времени жизни (Lifetimes) контейнеров в C# (ASP.NET Core DI)

В ASP.NET Core Dependency Injection существует четыре основные области времени жизни (Service Lifetimes), которые определяют, как и когда экземпляры сервисов создаются и уничтожаются контейнером внедрения зависимостей. Правильный выбор времени жизни критичен для производительности, управления ресурсами и избежания ошибок (например, утечек памяти или неправильного состояния).

1. Transient (Мгновенная)

Описание: Экземпляр сервиса создается каждый раз, когда он запрашивается из контейнера. Это наиболее «чистый» подход с точки зрения изоляции. Использование: Подходит для легковесных, статусных (stateful) или требующих изоляции сервисов. Например, сервисы, обрабатывающие отдельный HTTP-запрос, где каждому запросу нужна своя копия. Регистрация:

services.AddTransient<IMyService, MyService>();

Пример: Сервис для валидации данных, который не хранит состояние между вызовами.

2. Scoped (Область действия)

Описание: Экземпляр создается один раз в рамках области действия (scope). В веб-приложении каждая область действия обычно соответствует одному HTTP-запросу (Request). В рамках одного запроса все потребители получают один и тот же экземпляр. Для других запросов создаются новые экземпляры. Использование: Идеально для сервисов, которые должны сохранять состояние в рамках одного запроса, но изолироваться между запросами. Классический пример — DbContext Entity Framework Core. Регистрация:

services.AddScoped<IMyRepository, MyRepository>();

Важно: Вне контекста веб-запроса (например, в фоновой задаче) вы должны создать область вручную с помощью IServiceScopeFactory.

3. Singleton (Одиночка)

Описание: Экземпляр создается один раз за все время жизни приложения и используется всеми потребителями. Контейнер возвращает один и тот же экземпляр при каждом запросе. Использование: Для статичных (stateless), тяжеловесных сервисов или сервисов-кэшей, где необходимо разделяемое состояние на все приложение. Пример: кэш в памяти, логгер, конфигурация. Регистрация:

services.AddSingleton<IMyCacheService, MyCacheService>();

Предупреждение: Singleton-сервисы должны быть потокобезопасными, так как к ним может происходить одновременный доступ из множества потоков (запросов).

4. Instance (Экземпляр)

Описание: Это вариация Singleton, где вы предоставляете готовый экземпляр при регистрации, и контейнер всегда возвращает именно его. Время жизни управляется вами, а не контейнером. Использование: Когда нужно зарегистрировать предварительно сконфигурированный объект или объект, созданный не через контейнер (например, экземпляр из фабрики). Регистрация:

var myInstance = new MyService();
services.AddSingleton<IMyService>(myInstance);
// Или
services.AddSingleton<IMyService>(_ => myInstance);

Ключевые различия и рекомендации

• Производительность: Transient может создавать нагрузку, если сервис тяжелый и запрашивается часто. Singleton экономит ресурсы, но требует осторожности.
• Зависимости: Время жизни зависимого сервиса не должно превышать время жизни сервиса-потребика. Это критичное правило! Например:

    *   **Нельзя** внедрять Scoped-сервис в Singleton-сервис (Scoped «переживет» свой Scope и станет невалидным).
    *   Transient-сервис, зависящий от Scoped-сервиса, сам становится **фактически Scoped** в рамках этого Scope.

```csharp
// ОПАСНО: DbContext (Scoped) будет захвачен Singleton'ом.
public class MySingletonService
{
    public MySingletonService(MyDbContext dbContext) { } // Приведет к ошибке или утечке!
}
```

• Особенности в веб-приложениях: Scoped-сервисы в ASP.NET Core привязываются к контексту запроса. Если вы попытаетесь разрешить Scoped-сервис вне Scope (например, в конструкторе Singleton), вы получите исключение InvalidOperationException.

Создание Scope вручную (для фоновых задач или консольных приложений)

public class BackgroundWorker
{
    private readonly IServiceScopeFactory _scopeFactory;
    public BackgroundWorker(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    public void DoWork()
    {
        using (var scope = _scopeFactory.CreateScope())
        {
            var scopedService = scope.ServiceProvider.GetRequiredService<IMyScopedService>();
            // Работаем с scopedService в изолированной области
        }
    }
}

Вывод: Понимание областей времени жизни — это основа корректной архитектуры приложения с использованием DI. Неправильный выбор может привести к тонким и сложным для отладки ошибкам, связанным с состоянием, блокировками и утечками ресурсов. Всегда анализируйте, нужно ли сервису состояние, как оно должно изолироваться и как долго сервис должен жить.