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

Выбор типа времени жизни сервиса при работе с БД в ASP.NET Core

При работе с базой данных в ASP.NET Core я преимущественно использую Scoped (с областью действия) тип времени жизни для сервисов, которые обрабатывают операции с БД. Это обусловлено архитектурными особенностями веб-приложений и требованиями к управлению ресурсами.

Почему Scoped является оптимальным выбором?

Scoped означает, что один экземпляр сервиса создается для каждого HTTP-запроса (или области действия в рамках контейнера DI). Для работы с БД это критически важно по следующим причинам:

1. Управление контекстом DbContext — В ASP.NET Core Entity Framework Core использует DbContext, который должен быть привязан к одному запросу. Использование Scoped гарантирует, что один DbContext будет использоваться на протяжении всего запроса, обеспечивая корректную работу транзакций, отслеживания изменений и предотвращая проблемы с параллельным доступом.

2. Изоляция транзакций и данных — Каждый запрос работает с собственной изолированной сессией БД. Это предотвращает случайное использование данных или транзакций из другого запроса, что могло бы произойти при использовании Singleton.

3. Баланс между производительностью и безопасностью — Scoped обеспечивает повторное использование сервиса внутри одного запроса (например, несколько репозиториев могут использовать один DbContext), но создает новый для следующего запроса. Это более эффективно, чем Transient (где создается новый экземпляр каждый раз), и безопаснее, чем Singleton.

Практический пример регистрации Scoped сервисов

В Startup.cs или Program.cs при использовании .NET 6+:

// Регистрация DbContext с временем жизни Scoped
builder.Services.AddDbContext<ApplicationDbContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection")));

// Регистрация репозитория или сервиса работы с БД также как Scoped
builder.Services.AddScoped<IProductRepository, ProductRepository>();
builder.Services.AddScoped<IOrderService, OrderService>();

Сравнение с другими типами времени жизни

• Transient — Создается новый экземпляр каждый раз при обращении к сервису. Для БД это может привести к созданию множества DbContext внутри одного запроса, что увеличивает нагрузку и может вызвать проблемы с управлением транзакциями.

• Singleton — Один экземпляр на все время работы приложения. Для DbContext это категорически не рекомендуется, так как приводит к:

  • Некорректному отслеживанию сущностей (одни данные смешиваются между запросами)
  • Проблемам с параллельным выполнением запросов
  • Невозможности управления транзакциями на уровне запроса
  • Утечке памяти из-за накопления отслеживаемых объектов

• Scoped в не-веб контексте — В приложениях без HTTP-контекста (например, консольные приложения, background services) можно создать область действия искусственно с помощью IServiceScopeFactory.

Особые случаи и рекомендации

1. Для кэширования или общих ресурсов — Если сервис работы с БД включает кэширование, которое должно быть общим для всех запросов, можно использовать отдельный Singleton сервис для кэша, но сам DbContext остается Scoped.

2. Background задачи — В долго выполняющихся задачах (например, в hosted services) я создаю область действия через IServiceScope для каждой операции:

public class BackgroundProcessor : BackgroundService
{
    private readonly IServiceScopeFactory _scopeFactory;

    public BackgroundProcessor(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        using (var scope = _scopeFactory.CreateScope())
        {
            var dbContext = scope.ServiceProvider.GetRequiredService<ApplicationDbContext>();
            // Операции с БД в своей области
        }
    }
}

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

Scoped тип времени жизни обеспечивает корректную работу с БД в веб-приложениях, изолируя контекст запроса, управляя ресурсами эффективно и предотвращая конфликты. Это стандартная практика в ASP.NET Core, которая подтверждена документацией Microsoft и реальным опытом построения масштабируемых приложений.