Соглашения внедрения зависимостей в .NET: время жизни, области видимости и ловушка captive dependency

Что это

Документация .NET описывает встроенный контейнер: сервисы добавляются в IServiceCollection при старте (AddTransient, AddScoped, AddSingleton или их варианты с ключами), BuildServiceProvider либо generic host создаёт IServiceProvider, а потребители получают зависимости через публичный конструктор. Transient-сервисы создаются заново при каждом запросе экземпляра; scoped-сервисы — по одному разу на область видимости, которой в ASP.NET Core выступает HTTP-запрос; singleton-сервисы — один раз на всё время жизни контейнера. Контейнер освобождает (dispose) то, что сам создал: экземпляры transient и scoped — по окончании их области видимости, singleton — при остановке приложения. Если у типа несколько конструкторов, выбирается тот, у которого больше всего параметров, разрешимых через DI, а при неоднозначности выбрасывается исключение.

Почему это важно

Инженеры, пришедшие из Spring (где по умолчанию singleton) или из фреймворков без контейнера, склонны регистрировать всё как singleton или разрешать сервисы вручную. Страница рекомендаций называет возникающий в результате баг captive dependency: более долгоживущий сервис удерживает более короткоживущий, поэтому DbContext, рассчитанный «на один запрос», но захваченный singleton'ом, незаметно оказывается общим для всех запросов. Страница о временах жизни утверждает, что scoped-сервис нельзя разрешать из singleton — ни через внедрение в конструктор, ни через IServiceProvider; задокументированное решение — создавать явную область видимости через IServiceScopeFactory.

Как применять

• По умолчанию используйте transient для сервисов без состояния, scoped — для состояния в рамках одного запроса (DbContext, unit of work), singleton — только для общего, потокобезопасного и дорогого в создании состояния; рекомендации требуют потокобезопасности singleton'ов и предупреждают о рисках связности и потребления памяти.
• В конструкторах зависите от интерфейсов и не делайте в конструкторах ничего, кроме присваивания.
• Никогда не вызывайте Dispose у внедрённого сервиса и не регистрируйте типы IDisposable как transient, если они могут быть разрешены из корневого провайдера; рекомендации указывают, что такие экземпляры удерживаются вплоть до освобождения самого контейнера.
• Не вызывайте BuildServiceProvider в процессе конфигурирования сервисов и не используйте GetService в роли service locator'а; оба варианта числятся в списке антипаттернов.
• Держите валидацию областей видимости включённой: хост для разработки проверяет, что scoped-сервисы не разрешаются ни из корня, ни через внедрение в singleton, а validateScopes: true у BuildServiceProvider делает то же самое в остальных случаях.
• В hosted- или background-сервисах внедряйте IServiceScopeFactory и создавайте отдельную область видимости на каждую единицу работы.

Подводные камни

Статический доступ к провайдеру (захваченный где-то ApplicationServices) числится среди практик, которых стоит избегать: рекомендации утверждают, что преимущества DI теряются, стоит смешать его со статическим доступом к объектам. Хранение конфигурации или пользовательских данных прямо в контейнере вместо использования options pattern. Для сервисов с ключом на параметре нужен атрибут [FromKeyedServices("key")]. Повторная регистрация одного и того же сервиса — не ошибка с точки зрения синтаксиса, и её легко упустить из виду.