Тег: dependency-injection

До Aspire 13.5.4 каждый health check AppHost для ресурса AddKafka создавал новый producer Confluent, который никто не освобождал, поэтому потоки опроса накапливались, а AppHost нагружал CPU. Исправление и ловушка HealthCheckRegistration.Factory, стоящая за ним, касаются и ваших собственных health checks.

Singleton не может внедрить DbContext, но может внедрить IDbContextFactory<T>, потому что AddDbContextFactory по умолчанию регистрирует фабрику как singleton. Создавайте и освобождайте по одному контексту на вызов и никогда не сохраняйте экземпляр.

Реализуйте IValidateOptions<T>, зарегистрируйте его во внедрении зависимостей и добавьте ValidateOnStart, чтобы неверный appsettings.json убивал процесс, а не первый запрос, который его затронет. Разбираются перегрузка Validate<TValidator>() из .NET 11, асинхронная валидация через IAsyncValidateOptions<T> и три случая, когда ValidateOnStart молча ничего не делает.

По умолчанию используйте IOptions<T>. Берите IOptionsMonitor<T>, когда синглтон должен видеть перезагрузку конфигурации, и IOptionsSnapshot<T> только тогда, когда scoped-потребителю нужно значение, стабильное в пределах одного запроса. Решает время жизни потребителя, а не форма настроек.

EF Core выбрасывает это, когда AddDbContext не вызывался, вызван после Build или конструктор контекста принимает не тот DbContextOptions. Регистрируйте до Build и используйте DbContextOptions<ВашКонтекст>.

Зарегистрируйте несколько реализаций одного типа сервиса под ключом с помощью AddKeyedSingleton/Scoped/Transient, а затем разрешите их через [FromKeyedServices], GetRequiredKeyedService или KeyedService.AnyKey. Регистрации с ключом и без ключа находятся в раздельных таблицах, и именно это сбивает с толку почти всех.

BackgroundService является синглтоном, поэтому не может напрямую внедрить scoped-сервис вроде DbContext. Внедрите IServiceScopeFactory, открывайте один scope на единицу работы через CreateAsyncScope, разрешайте сервис внутри него и освобождайте scope по завершении работы.

Пошаговый чек-лист для удаления MediatR 12-14 и замены обработчиков IRequest, ISender, pipeline behaviors и INotification на простые классы-сервисы и внедрение через конструктор.

Для нового кода простые сервисные классы - лучший выбор по умолчанию. Смена лицензии MediatR в июле 2025 важна, только если вы выше порога Community в 5 млн долларов или отвергаете copyleft RPL-1.5. Сохраняйте MediatR, когда pipeline behaviors несут реальную нагрузку.

Валидация области в ASP.NET Core выбрасывает это, когда singleton захватил бы scoped-зависимость на весь процесс. Сделайте потребителя scoped или внедрите IServiceScopeFactory и создавайте область по требованию.