День девятьсот восемьдесят восьмой. #ЗаметкиНаПолях
Основные Заблуждения о Внедрении Зависимостей в ASP.NET Core. Продолжение
Начало

2. DI фреймворк всегда проверяет захват зависимостей
Захват зависимостей - это своего рода антипаттерн внедрения зависимостей, который может привести к ошибкам в вашем коде.

Всё, что вам нужно сделать, чтобы получить проблему с захватом зависимости, - это внедрить класс с более коротким временем жизни в класс с более длительным временем жизни. Например, внедрите сервис, ограниченный областью действия, в синглтон. В этом случае класс, ограниченный областью действия, не будет создаваться и удаляться для каждого веб-запроса. Он будет иметь то же время жизни, что и синглтон, и фактически станет синглтоном.

Почему это действительно проблема?
В веб-приложениях экземпляры синглтонов, хранящие, например, кэшированные данные, спроектированы для обеспечения потоковой безопасности, чтобы избежать ошибок параллелизма, когда несколько запросов обращаются к одному и тому же синглтон объекту. Однако классы, ограниченные областью действия, не обязательно должны быть потокобезопасными, если разработчики не запускают дополнительные параллельные потоки в веб-запросе.

Проблема захвата зависимости продлевает время жизни объекта. Если потоконебезопасный класс, предназначенный для жизни внутри области действия, становится синглтоном, в приложении будут возникать ошибки параллелизма.

ASP.NET Core защищает разработчиков от этой проблемы, проверяя граф зависимостей на наличие захвата зависимостей и генерируя исключение, если они обнаружены.

public void ConfigureServices(IServiceCollection services)
{
  services.AddSingleton<UserService>();
  services.AddScoped<IUserRepository, UserRepository>();
}
public class UserService
{
  public UserService(IUserRepository userRepository) 
  { 
  }
}
public class UserRepository : IUserRepository
{
}

Выполнение приведенного выше кода приведёт к исключению InvalidOperationException, из-за того, что класс, ограниченный областью действия, IUserRepository не может быть использован из синглтона UserService.

Заблуждение состоит в том, что проверка ASP.NET Core на наличие захвата зависимостей всегда будет работать. Однако в ядре ASP.NET проверка зависимостей по умолчанию выполняется только в среде разработки (Development).

Если код не был хорошо протестирован локально, в других средах, кроме среды разработки, исключения не возникнет. Вместо этого время жизни сервисов будет без предупреждения увеличено, что вызовет потенциальные проблемы с параллелизмом и возможно другие.

Чтобы гарантировать, что код всегда проверяется на наличие захвата зависимостей, установите для параметра ValidateScopes значение true в точке входа приложения:

public static IHostBuilder CreateHostBuilder(string[] args) =>
  Host.CreateDefaultBuilder(args)
    .ConfigureWebHostDefaults(webBuilder =>
    {
      webBuilder.UseStartup<Startup>();
    })
    .UseDefaultServiceProvider((context, options) => {
      options.ValidateScopes = true;
    });

Также вы можете указать свойство

options.ValidateOnBuild = true;

Эта функция добавлена в .NET Core 3.0. Проверка сервисов будет производиться во время построения провайдера сервисов, т.е. во время старта приложения, а не при запросе сервиса, который невозможно разрешить.

Окончание следует…

Источник: https://levelup.gitconnected.com/top-misconceptions-about-dependency-injection-in-asp-net-core-c6a7afd14eb4