Какие типы жизненного цикла сервисов существуют в ASP.NET Core?

А, слушай, про эту вашу инъекцию зависимостей в ASP.NET Core! Ну, там же три главных типа, как они живут, да? Это ж надо понимать, а то потом такие косяки будут, что охуеешь.

Вот смотри, есть три штуки:

Transient — это как одноразовый стаканчик. Каждый раз, когда кто-то просит этот сервис, контейнер тебе новый, свеженький делает. Зарегистрировать — AddTransient. Юзать это для всякой легкой хуйни, которая не должна состояние хранить. Ну, типа Random там, или локализатор какой. Сделал дело — выкинул, похуй.

Scoped — вот это уже поинтереснее. Создается один раз на область видимости. В веб-приложении — один раз на HTTP-запрос. Все в рамках одного запроса юзают один и тот же экземпляр. Регистрация — AddScoped. Это для всего, что завязано на контекст запроса: твой DbContext из Entity Framework, репозитории, сервисы бизнес-логики. Удобно, логично.

Singleton — это уже монументальная хуйня. Создается один раз на всё время работы приложения и живёт, пока приложение не сдохнет. AddSingleton. Это для сервисов с общим состоянием или которые овердохуища ресурсов жрут при создании: кэши (IMemoryCache), клиенты (через фабрику), конфигурация какая-нибудь глобальная.

А теперь, внимание, ебушки-воробушки, главные грабли, на которые все наступают:

1. Singleton НИ В КОЕМ СЛУЧАЕ не должен зависеть от Scoped или Transient сервисов. Вообще, блядь, никогда! Это называется captive dependency — зависимость в плену. Представь: у тебя Singleton-сервис, как царь и бог, живёт вечно. А ты в него засунул Scoped-сервис, который по задумке должен умирать после каждого запроса. И что? А него нихуя не умрёт! Он будет висеть в памяти, как проклятый. Особенно весело с DbContext — он кэшировать данные начнёт, соединения не будет отпускать, и в итоге у тебя приложение ебнет по памяти. Пиздец и разбор полётов.

   // НЕ, НЕ, НЕ! СОВСЕМ НЕ ТАК! Singleton, зависящий от Scoped — это билет в ад.
   public class BadCacheService
   {
       private readonly AppDbContext _context; // Scoped, Карл!
       public BadCacheService(AppDbContext context) => _context = context; // Вот тут и начинается пиздец.
   }

2. А если надо Scoped сервис юзать вне HTTP-запроса? Ну, в фоновой задаче, в каком-нибудь IHostedService. Там же запроса нет, scope-а нет. И что делать? А вот так: руками создавать область видимости через IServiceScopeFactory. Смотри, как гениально просто:

   public class BackgroundWorker : IHostedService
   {
       private readonly IServiceScopeFactory _scopeFactory; // Берём фабрику
       public BackgroundWorker(IServiceScopeFactory scopeFactory) => _scopeFactory = scopeFactory;
   
       public async Task DoWorkAsync()
       {
           // Создаём новую, чистенькую область видимости
           using (var scope = _scopeFactory.CreateScope())
           {
               // Достаём из неё Scoped-сервис
               var scopedService = scope.ServiceProvider.GetRequiredService<IMyScopedService>();
               await scopedService.ProcessDataAsync();
           } // Всё! Здесь область закроется, и все Scoped-сервисы внутри неё корректно почистятся. Красота.
       }
   }

Так как же выбирать-то, спросишь ты? Да всё просто, чувак.

• Scoped — это твой дефолтный, рабочий вариант для 90% сервисов, где есть какая-то логика, связанная с запросом или транзакцией. Начинай думать с него.
• Transient — для простых, безголовых утилиток, которые не хранят состояния между вызовами. Сделал — выбросил.
• Singleton — только для реально глобальных, общих штук, доступ к которым нужно как-то синхронизировать. Или которые так дороги в создании, что проще один раз создать и забыть. Но без фанатизма, а то опять captive dependency получишь, и волосы на жопе вылезут.