ASP.NET Core에서 종속성 주입

작성자: Kirk Larkin, Steve Smith, Scott AddieBrandon Dahler

ASP.NET Core는 클래스와 해당 종속성 간의 IoC(Inversion of Control)를 실현하는 기술인 DI(종속성 주입) 소프트웨어 디자인 패턴을 지원합니다.

MVC 컨트롤러 내의 종속성 주입에 대한 자세한 내용은 ASP.NET Core의 컨트롤러에 종속성 주입을 참조하세요.

웹앱이 아닌 애플리케이션에서 종속성 주입을 사용하는 방법에 대한 자세한 내용은 .NET의 종속성 주입을 참조하세요.

옵션의 종속성 주입에 대한 자세한 내용은 ASP.NET Core의 옵션 패턴를 참조하세요.

이 항목에서는 ASP.NET Core의 종속성 삽입에 관한 정보를 제공합니다. 종속성 주입 사용에 대한 기본 설명서는 .NET의 종속성 주입에 포함되어 있습니다.

예제 코드 살펴보기 및 다운로드 (다운로드 방법)

종속성 주입 개요

‘종속성’은 다른 개체가 종속된 개체입니다. 다른 클래스가 종속된 MyDependency 클래스에서 WriteMessage 메서드를 사용하는 다음 코드를 살펴보세요.

public class MyDependency
{
    public void WriteMessage(string message)
    {
        Console.WriteLine($"MyDependency.WriteMessage called. Message: {message}");
    }
}

클래스에서 MyDependency 클래스의 인스턴스를 만들어 WriteMessage 메서드를 사용할 수 있습니다. 다음 예제에서 MyDependency 클래스는 IndexModel 클래스의 종속성입니다.

public class IndexModel : PageModel
{
    private readonly MyDependency _dependency = new MyDependency();

    public void OnGet()
    {
        _dependency.WriteMessage("IndexModel.OnGet created this message.");
    }
}

이 클래스는 MyDependency 클래스를 만들고 이 클래스에 직접 종속됩니다. 이전 예제와 같은 코드 종속성은 문제가 있으며 다음과 같은 이유로 사용하지 않아야 합니다.

  • MyDependency를 다른 구현으로 바꾸려면 IndexModel 클래스를 수정해야 합니다.
  • MyDependency에 종속성이 있으면 IndexModel 클래스에서 해당 종속성도 구성해야 합니다. 여러 클래스가 MyDependency에 종속되어 있는 대형 프로젝트에서는 구성 코드가 앱 전체에 분산됩니다.
  • 이 구현은 단위 테스트하기가 어렵습니다. 앱에서 모의 또는 스텁 MyDependency 클래스를 사용해야 하지만, 이 방법에서는 가능하지 않습니다.

종속성 주입은 다음을 통해 이러한 문제를 해결합니다.

  • 인퍼테이스 또는 기본 클래스를 사용하여 종속성 구현을 추상화합니다.
  • 서비스 컨테이너에 종속성 등록. ASP.NET Core는 서비스 컨테이너인 IServiceProvider를 기본 제공합니다. 서비스는 일반적으로 앱의 Startup.ConfigureServices 메서드에서 등록됩니다.
  • 서비스가 사용되는 클래스의 생성자에 주입됨. 프레임워크가 종속성의 인스턴스를 만들고 더 이상 필요하지 않으면 삭제하는 작업을 담당합니다.

샘플 앱에서 IMyDependency 인터페이스는 WriteMessage 메서드를 정의합니다.

public interface IMyDependency
{
    void WriteMessage(string message);
}

이 인터페이스는 구체적인 형식 MyDependency에서 구현됩니다.

public class MyDependency : IMyDependency
{
    public void WriteMessage(string message)
    {
        Console.WriteLine($"MyDependency.WriteMessage Message: {message}");
    }
}

샘플 앱에서는 IMyDependency 서비스를 구체적인 MyDependency 형식으로 등록합니다. AddScoped 메서드는 단일 요청의 수명인 범위가 지정된 수명으로 서비스를 등록합니다. 서비스 수명에 대해서는 이 항목의 뒷부분에서 설명합니다.

public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<IMyDependency, MyDependency>();

    services.AddRazorPages();
}

샘플 앱에서는 IMyDependency 서비스가 요청되며 이 서비스는 WriteMessage 메서드를 호출하는 데 사용됩니다.

public class Index2Model : PageModel
{
    private readonly IMyDependency _myDependency;

    public Index2Model(IMyDependency myDependency)
    {
        _myDependency = myDependency;            
    }

    public void OnGet()
    {
        _myDependency.WriteMessage("Index2Model.OnGet");
    }
}

DI 패턴을 사용하여 컨트롤러는 다음을 수행합니다.

  • 컨트롤러는 구체적인 형식 MyDependency를 사용하지 않고 구현되는 IMyDependency 인터페이스만 사용합니다. 따라서 컨트롤러에서 사용하는 구현을 컨트롤러를 수정하지 않고 쉽게 변경할 수 있습니다.
  • MyDependency의 인스턴스를 만들지 않습니다. 해당 인스턴스는 DI 컨테이너에 의해 만들어집니다.

IMyDependency 인터페이스의 구현을 기본 제공 로깅 API를 사용하여 향상할 수 있습니다.

public class MyDependency2 : IMyDependency
{
    private readonly ILogger<MyDependency2> _logger;

    public MyDependency2(ILogger<MyDependency2> logger)
    {
        _logger = logger;
    }

    public void WriteMessage(string message)
    {
        _logger.LogInformation( $"MyDependency2.WriteMessage Message: {message}");
    }
}

업데이트된 ConfigureServices 메서드는 새 IMyDependency 구현을 등록합니다.

public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<IMyDependency, MyDependency2>();

    services.AddRazorPages();
}

MyDependency2는 생성자에서 요청하는 ILogger<TCategoryName>에 종속됩니다. ILogger<TCategoryName>프레임워크에서 제공하는 서비스입니다.

종속성 주입을 연결된 방식으로 사용하는 일은 특별한 경우가 아닙니다. 요청된 각 종속성은 차례로 자체 종속성을 요청합니다. 컨테이너는 그래프의 종속성을 해결하고 완전히 해결된 서비스를 반환합니다. 해결해야 하는 종속성이 모인 집합은 일반적으로 종속성 트리, 종속성 그래프 또는 개체 그래프라고 합니다 .

컨테이너는 개방형 형식(제네릭)을 활용하여 ILogger<TCategoryName>을 해결하므로 모든 생성된 형식(제네릭)을 등록하지 않아도 됩니다.

종속성 주입 용어에서 서비스는 다음과 같습니다.

  • 일반적으로 다른 개체에 IMyDependency 서비스와 같은 서비스를 제공하는 개체입니다.
  • 서비스에서 웹 서비스를 사용할 수 있지만 웹 서비스와 관련 있는 것은 아닙니다.

해당 프레임워크는 강력한 로깅 시스템을 제공합니다. 이전 예제에 표시된 IMyDependency 구현은 로깅을 구현하는 것이 아니라 기본 DI를 보여 주기 위해 작성되었습니다. 대부분의 앱에서는 로거를 작성할 필요가 없습니다. 다음 코드에서는 ConfigureServices에 서비스를 등록하지 않아도 되는 기본 로깅을 사용하는 방법을 보여 줍니다.

public class AboutModel : PageModel
{
    private readonly ILogger _logger;

    public AboutModel(ILogger<AboutModel> logger)
    {
        _logger = logger;
    }
    
    public string Message { get; set; }

    public void OnGet()
    {
        Message = $"About page visited at {DateTime.UtcNow.ToLongTimeString()}";
        _logger.LogInformation(Message);
    }
}

위의 코드를 사용하여 프레임워크에서 로깅을 제공하므로 ConfigureServices를 업데이트할 필요가 없습니다.

시작에 삽입된 서비스

서비스를 Startup 생성자 및 Startup.Configure 메서드에 삽입할 수 있습니다.

제네릭 호스트(IHostBuilder)를 사용할 경우 다음 서비스 유형만 Startup 생성자에 삽입할 수 있습니다.

DI 컨테이너에 등록된 모든 서비스를 Startup.Configure 메서드에 삽입할 수 있습니다.

public void Configure(IApplicationBuilder app, ILogger<Startup> logger)
{
    ...
}

자세한 내용은 ASP.NET Core에서 앱 시작시작 시 구성 액세스를 참조하세요.

확장 메서드를 사용하여 서비스 그룹 등록

ASP.NET Core 프레임워크에서는 관련 서비스 그룹을 등록하는 규칙을 사용합니다. 규칙은 단일 Add{GROUP_NAME} 확장 메서드를 사용하여 프레임워크 기능에 필요한 모든 서비스를 등록하는 것입니다. 예를 들어 AddControllers 확장 메서드는 MVC 컨트롤러에 필요한 서비스를 등록합니다.

다음 코드는 개별 사용자 계정을 사용하는 Razor Pages 템플릿으로 생성되며 확장 메서드 AddDbContextAddDefaultIdentity를 사용하여 컨테이너에 서비스를 추가하는 방법을 보여 줍니다.

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(
            Configuration.GetConnectionString("DefaultConnection")));
    services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
        .AddEntityFrameworkStores<ApplicationDbContext>();
    services.AddRazorPages();
}

서비스를 등록하고 옵션을 구성하는 다음 ConfigureServices 메서드를 고려합니다.

public void ConfigureServices(IServiceCollection services)
{
    services.Configure<PositionOptions>(
        Configuration.GetSection(PositionOptions.Position));
    services.Configure<ColorOptions>(
        Configuration.GetSection(ColorOptions.Color));

    services.AddScoped<IMyDependency, MyDependency>();
    services.AddScoped<IMyDependency2, MyDependency2>();

    services.AddRazorPages();
}

관련 등록 그룹을 확장 메서드로 이동하여 서비스를 등록할 수 있습니다. 예를 들어, 구성 서비스는 다음 클래스에 추가됩니다.

using ConfigSample.Options;
using Microsoft.Extensions.Configuration;

namespace Microsoft.Extensions.DependencyInjection
{
    public static class MyConfigServiceCollectionExtensions
    {
        public static IServiceCollection AddConfig(
             this IServiceCollection services, IConfiguration config)
        {
            services.Configure<PositionOptions>(
                config.GetSection(PositionOptions.Position));
            services.Configure<ColorOptions>(
                config.GetSection(ColorOptions.Color));

            return services;
        }
    }
}

나머지 서비스는 유사한 클래스에 등록됩니다. 다음 ConfigureServices 메서드는 새 확장 메서드를 사용하여 서비스를 등록합니다.

public void ConfigureServices(IServiceCollection services)
{
    services.AddConfig(Configuration)
            .AddMyDependencyGroup();

    services.AddRazorPages();
}

참고:services.Add{GROUP_NAME} 확장 메서드는 서비스를 추가하고 잠재적으로 구성합니다. 예를 들어 AddControllersWithViews는 보기에 필요한 서비스 MVC 컨트롤러를 추가하고 AddRazorPages는 Razor Pages에 필요한 서비스를 추가합니다. 앱에서 이 명명 규칙을 따르는 것이 좋습니다. 확장 메서드를 Microsoft.Extensions.DependencyInjection 네임스페이스에 배치하여 서비스 등록 그룹을 캡슐화합니다.

서비스 수명

.NET의 종속성 주입서비스 수명을 참조하세요.

미들웨어에서 범위 지정 서비스를 사용하려면 다음 방법 중 하나를 사용합니다.

  • 미들웨어의 Invoke 또는 InvokeAsync 메서드에 서비스를 삽입합니다. 생성자 주입을 사용하면 범위 지정 서비스가 싱글톤처럼 작동하게 하므로 런타임 예외가 throw됩니다. 수명 및 등록 옵션 섹션의 샘플에서는 InvokeAsync 방법을 보여 줍니다.
  • 팩터리 기반 미들웨어를 사용합니다. 이 방법을 사용하여 등록된 미들웨어는 클라이언트를 요청(연결)할 때마다 활성화되어, 범위 지정 서비스를 미들웨어의 InvokeAsync 메서드에 삽입할 수 있도록 해줍니다.

자세한 내용은 사용자 지정 ASP.NET Core 미들웨어 작성를 참조하세요.

서비스 등록 메서드

.NET의 종속성 주입서비스 등록 메서드를 참조하세요.

테스트를 위한 형식을 모의할 때 여러 구현을 사용하는 것이 일반적입니다.

구현 형식만으로 서비스를 등록하는 것은 동일한 구현 및 서비스 형식으로 해당 서비스를 등록하는 것과 같습니다. 따라서 명시적 서비스 형식을 사용하지 않는 메서드를 사용하여 서비스의 여러 구현을 등록할 수 없습니다. 이러한 메서드는 서비스의 여러 ‘인스턴스’를 등록할 수 있지만 모두 동일한 ‘구현’ 형식을 사용합니다.

위의 서비스 등록 메서드 중 하나를 사용하여 동일한 서비스 형식의 여러 서비스 인스턴스를 등록할 수 있습니다. 다음 예제에서는 IMyDependency를 서비스 형식으로 사용하여 AddSingleton을 두 번 호출합니다. 두 번째 AddSingleton 호출은 IMyDependency로 확인되면 이전 호출을 재정의하고 IEnumerable<IMyDependency>를 통해 여러 서비스가 확인되면 이전 호출에 추가됩니다. 서비스는 IEnumerable<{SERVICE}>를 통해 해결될 때 등록된 순서로 나타납니다.

services.AddSingleton<IMyDependency, MyDependency>();
services.AddSingleton<IMyDependency, DifferentDependency>();

public class MyService
{
    public MyService(IMyDependency myDependency, 
       IEnumerable<IMyDependency> myDependencies)
    {
        Trace.Assert(myDependency is DifferentDependency);

        var dependencyArray = myDependencies.ToArray();
        Trace.Assert(dependencyArray[0] is MyDependency);
        Trace.Assert(dependencyArray[1] is DifferentDependency);
    }
}

생성자 주입 동작

.NET의 종속성 주입생성자 주입 동작을 참조하세요.

Entity Framework 컨텍스트

기본적으로 Entity Framework 컨텍스트는 범위가 지정된 수명을 사용하여 서비스 컨테이너에 추가됩니다. 이는 웹앱 데이터베이스 작업이 일반적으로 클라이언트 요청에 따라 범위가 지정되기 때문입니다. 다른 수명을 사용하려면 AddDbContext 오버로드를 사용하여 수명을 지정합니다. 지정된 수명의 서비스는 서비스보다 수명이 짧은 데이터베이스 컨텍스트를 사용해서는 안됩니다.

수명 및 등록 옵션

서비스 수명 및 등록 옵션 간의 차이점을 살펴보려면 작업을 식별자인 OperationId가 부여된 작업으로 나타내는 다음 인터페이스를 고려해 보세요. 다음 인터페이스들에 대해 작업 서비스의 수명을 구성하는 방법에 따라 컨테이너는 클래스에서 요청할 때 서비스의 같은 인스턴스나 다른 인스턴스를 제공합니다.

public interface IOperation
{
    string OperationId { get; }
}

public interface IOperationTransient : IOperation { }
public interface IOperationScoped : IOperation { }
public interface IOperationSingleton : IOperation { }

다음 Operation 클래스는 위의 모든 인터페이스를 구현합니다. Operation 생성자는 GUID를 생성하고 마지막 4자를 OperationId 속성에 저장합니다.

public class Operation : IOperationTransient, IOperationScoped, IOperationSingleton
{
    public Operation()
    {
        OperationId = Guid.NewGuid().ToString()[^4..];
    }

    public string OperationId { get; }
}

Startup.ConfigureServices 메서드는 명명된 수명에 따라 Operation 클래스의 여러 등록을 만듭니다.

public void ConfigureServices(IServiceCollection services)
{
    services.AddTransient<IOperationTransient, Operation>();
    services.AddScoped<IOperationScoped, Operation>();
    services.AddSingleton<IOperationSingleton, Operation>();

    services.AddRazorPages();
}

샘플 앱에서는 요청 내의 개체 수명과 요청 간의 개체 수명을 모두 보여 줍니다. IndexModel 및 미들웨어는 각 IOperation 형식을 요청하고 각각에 대한 OperationId를 기록합니다.

public class IndexModel : PageModel
{
    private readonly ILogger _logger;
    private readonly IOperationTransient _transientOperation;
    private readonly IOperationSingleton _singletonOperation;
    private readonly IOperationScoped _scopedOperation;

    public IndexModel(ILogger<IndexModel> logger,
                      IOperationTransient transientOperation,
                      IOperationScoped scopedOperation,
                      IOperationSingleton singletonOperation)
    {
        _logger = logger;
        _transientOperation = transientOperation;
        _scopedOperation    = scopedOperation;
        _singletonOperation = singletonOperation;
    }

    public void  OnGet()
    {
        _logger.LogInformation("Transient: " + _transientOperation.OperationId);
        _logger.LogInformation("Scoped: "    + _scopedOperation.OperationId);
        _logger.LogInformation("Singleton: " + _singletonOperation.OperationId);
    }
}

IndexModel과 유사한 미들웨어는 동일한 서비스를 해결합니다.

public class MyMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger _logger;

    private readonly IOperationTransient _transientOperation;
    private readonly IOperationSingleton _singletonOperation;

    public MyMiddleware(RequestDelegate next, ILogger<MyMiddleware> logger,
        IOperationTransient transientOperation,
        IOperationSingleton singletonOperation)
    {
        _logger = logger;
        _transientOperation = transientOperation;
        _singletonOperation = singletonOperation;
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context,
        IOperationScoped scopedOperation)
    {
        _logger.LogInformation("Transient: " + _transientOperation.OperationId);
        _logger.LogInformation("Scoped: "    + scopedOperation.OperationId);
        _logger.LogInformation("Singleton: " + _singletonOperation.OperationId);

        await _next(context);
    }
}

public static class MyMiddlewareExtensions
{
    public static IApplicationBuilder UseMyMiddleware(this IApplicationBuilder builder)
    {
        return builder.UseMiddleware<MyMiddleware>();
    }
}

범위가 지정된 서비스는 InvokeAsync 메서드에서 해결해야 합니다.

public async Task InvokeAsync(HttpContext context,
    IOperationScoped scopedOperation)
{
    _logger.LogInformation("Transient: " + _transientOperation.OperationId);
    _logger.LogInformation("Scoped: "    + scopedOperation.OperationId);
    _logger.LogInformation("Singleton: " + _singletonOperation.OperationId);

    await _next(context);
}

로거 출력은 다음을 보여 줍니다.

  • Transient 개체는 항상 다릅니다. 임시 OperationId 값은 IndexModel과 미들웨어에서 다릅니다.
  • ‘범위가 지정된’ 개체는 각 요청에 대해 동일하지만 각 요청 간에 다릅니다.
  • ‘싱글톤’ 개체는 모든 요청에 동일합니다.

로깅 출력을 줄이려면 appsettings.Development.json 파일에서 “Logging:LogLevel:Microsoft:Error”를 설정합니다.

{
  "MyKey": "MyKey from appsettings.Developement.json",
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "System": "Debug",
      "Microsoft": "Error"
    }
  }
}

Main에서 서비스 호출

IServiceScopeFactory.CreateScope를 사용하여 IServiceScope를 만들어서 앱 범위 내로 범위가 지정된 서비스를 해결합니다. 이 방법은 시작 시 범위가 지정된 서비스에 액세스하여 초기화 작업을 실행하는 데 유용합니다.

다음 예제에서는 범위가 지정된 IMyDependency 서비스에 액세스하고 Program.Main에서 해당 WriteMessage 메서드를 호출하는 방법을 보여 줍니다.

public class Program
{
    public static void Main(string[] args)
    {
        var host = CreateHostBuilder(args).Build();

        using (var serviceScope = host.Services.CreateScope())
        {
            var services = serviceScope.ServiceProvider;

            try
            {
                var myDependency = services.GetRequiredService<IMyDependency>();
                myDependency.WriteMessage("Call services from main");
            }
            catch (Exception ex)
            {
                var logger = services.GetRequiredService<ILogger<Program>>();
                logger.LogError(ex, "An error occurred.");
            }
        }

        host.Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

범위 유효성 검사

.NET의 종속성 주입생성자 주입 동작을 참조하세요.

자세한 내용은 범위 유효성 검사를 참조하세요.

요청 서비스

ASP.NET Core 요청 내에서 사용할 수 있는 서비스는 HttpContext.RequestServices 컬렉션을 통해 노출됩니다. 요청 내에서 서비스가 요청되는 경우 서비스와 해당 종속성은 RequestServices 컬렉션에서 확인됩니다.

프레임워크는 요청당 범위를 만들고 RequestServices는 범위가 지정된 서비스 공급자를 공개합니다. 범위가 지정된 모든 서비스는 요청이 활성 상태인 동안 유효합니다.

참고

RequestServices 컬렉션에 서비스를 확인하는 것보다 생성자 매개 변수로 종속성을 요청하는 것을 선호합니다. 이 방법이 테스트하기 쉬운 클래스를 생성합니다.

종속성 주입을 위한 서비스 디자인

종속성 주입을 위한 서비스를 디자인하는 경우

  • 상태 저장 정적 클래스 및 멤버를 사용하지 마세요. 대신 싱글톤 서비스를 사용하도록 앱을 설계하여 전역 상태를 만들지 않도록 합니다.
  • 서비스 내의 종속 클래스를 직접 인스턴스화하지 마세요. 직접 인스턴스화는 코드를 특정 구현에 결합합니다.
  • 서비스를 작고 잘 구성되고 쉽게 테스트할 수 있도록 만듭니다.

클래스에 주입된 종속성이 많은 경우 클래스에 역할이 너무 많고 SRP(단일 책임 원칙)를 위반하는 것일 수 있습니다. 해당 책임 몇 가지를 새로운 클래스로 이동하여 클래스를 리팩터링해 보세요. Razor Pages의 페이지 모델 클래스 및 MVC 컨트롤러 클래스는 UI 고려 사항에 집중해야 합니다.

서비스 삭제

컨테이너는 자신이 만든 IDisposable 형식에 대해 Dispose를 호출합니다. 개발자는 컨테이너에서 확인된 서비스는 삭제해서는 안 됩니다. 형식 또는 팩터리가 싱글톤으로 등록된 경우 컨테이너에서 싱글톤을 자동으로 삭제합니다.

다음 예제에서는 서비스가 서비스 컨테이너에 의해 만들어지고 자동으로 삭제됩니다.

public class Service1 : IDisposable
{
    private bool _disposed;

    public void Write(string message)
    {
        Console.WriteLine($"Service1: {message}");
    }

    public void Dispose()
    {
        if (_disposed)
            return;

        Console.WriteLine("Service1.Dispose");
        _disposed = true;
    }
}

public class Service2 : IDisposable
{
    private bool _disposed;

    public void Write(string message)
    {
        Console.WriteLine($"Service2: {message}");
    }

    public void Dispose()
    {
        if (_disposed)
            return;

        Console.WriteLine("Service2.Dispose");
        _disposed = true;
    }
}

public interface IService3
{
    public void Write(string message);
}

public class Service3 : IService3, IDisposable
{
    private bool _disposed;

    public Service3(string myKey)
    {
        MyKey = myKey;
    }

    public string MyKey { get; }

    public void Write(string message)
    {
        Console.WriteLine($"Service3: {message}, MyKey = {MyKey}");
    }

    public void Dispose()
    {
        if (_disposed)
            return;

        Console.WriteLine("Service3.Dispose");
        _disposed = true;
    }
}
public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<Service1>();
    services.AddSingleton<Service2>();
    
    var myKey = Configuration["MyKey"];
    services.AddSingleton<IService3>(sp => new Service3(myKey));

    services.AddRazorPages();
}
public class IndexModel : PageModel
{
    private readonly Service1 _service1;
    private readonly Service2 _service2;
    private readonly IService3 _service3;

    public IndexModel(Service1 service1, Service2 service2, IService3 service3)
    {
        _service1 = service1;
        _service2 = service2;
        _service3 = service3;
    }

    public void OnGet()
    {
        _service1.Write("IndexModel.OnGet");
        _service2.Write("IndexModel.OnGet");
        _service3.Write("IndexModel.OnGet");
    }
}

디버그 콘솔에는 인덱스 페이지를 새로 고칠 때마다 다음과 같은 출력이 표시됩니다.

Service1: IndexModel.OnGet
Service2: IndexModel.OnGet
Service3: IndexModel.OnGet
Service1.Dispose

서비스 컨테이너에서 만들지 않은 서비스

다음 코드를 살펴보세요.

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton(new Service1());
    services.AddSingleton(new Service2());

    services.AddRazorPages();
}

위의 코드에서

  • 서비스 인스턴스가 서비스 컨테이너에 의해 만들어지지 않습니다.
  • 프레임워크가 서비스를 자동으로 삭제하지 않습니다.
  • 개발자가 서비스 삭제를 담당합니다.

임시 및 공유 인스턴스에 대한 IDisposable 지침

.NET의 종속성 주입임시 및 공유 인스턴스에 대한 IDisposable 지침을 참조하세요.

기본 서비스 컨테이너 바꾸기

.NET의 종속성 주입기본 서비스 컨테이너 바꾸기를 참조하세요.

권장 사항

.NET의 종속성 주입권장 사항을 참조하세요.

  • ‘서비스 로케이터 패턴’을 사용하지 마세요. 예를 들어 DI를 대신 사용할 수 있는 경우 서비스 인스턴스를 가져오기 위해 GetService를 호출하지 마세요.

    잘못된 예:

    잘못된 코드

    올바른 예:

    public class MyClass
    {
        private readonly IOptionsMonitor<MyOptions> _optionsMonitor;
    
        public MyClass(IOptionsMonitor<MyOptions> optionsMonitor)
        {
            _optionsMonitor = optionsMonitor;
        }
    
        public void MyMethod()
        {
            var option = _optionsMonitor.CurrentValue.Option;
    
            ...
        }
    }
    
  • 피해야 하는 또 다른 서비스 로케이터 변형은 런타임에 종속성을 해결하는 팩터리를 주입하는 것입니다. 이러한 두 가지 방법 모두 제어 반전 전략을 혼합합니다.

  • HttpContext(예: IHttpContextAccessor.HttpContext)에 정적으로 액세스하지 마세요.

  • ConfigureServices에서 BuildServiceProvider를 호출하지 마세요. 일반적으로 BuildServiceProvider는 개발자가 ConfigureServices에서 서비스를 해결하려는 경우 호출합니다. 구성에서 LoginPath를 로드하는 경우를 예로 들 수 있습니다. 다음 방법을 사용하지 마세요.

    BuildServiceProvider를 호출하는 잘못된 코드

    위 이미지에서 services.BuildServiceProvider 아래의 녹색 물결 모양 줄을 선택하면 다음 ASP0000 경고가 표시됩니다.

    ASP0000 애플리케이션 코드에서 ‘BuildServiceProvider’를 호출하면 싱글톤 서비스의 추가 복사본이 생성됩니다. ‘Configure’의 매개 변수로 종속성 주입 서비스와 같은 다른 방법을 고려하세요.

    BuildServiceProvider를 호출하면 두 번째 컨테이너가 만들어지므로, 조각난 싱글톤이 생성되고 여러 컨테이너의 개체 그래프를 참조할 수 있습니다.

    LoginPath를 가져오는 올바른 방법은 DI에 대한 옵션 패턴의 기본 제공 지원을 사용하는 것입니다.

    public void ConfigureServices(IServiceCollection services)
    {
        services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
            .AddCookie();
    
        services.AddOptions<CookieAuthenticationOptions>(
                            CookieAuthenticationDefaults.AuthenticationScheme)
            .Configure<IMyService>((options, myService) =>
            {
                options.LoginPath = myService.GetLoginPath();
            });
    
        services.AddRazorPages();
    }
    
  • 삭제 가능한 임시 서비스는 삭제를 위해 컨테이너에서 캡처됩니다. 따라서 최상위 컨테이너에서 해결할 경우 메모리 누수가 발생할 수 있습니다.

  • 범위 유효성 검사를 사용하여 범위가 지정된 서비스를 캡처하는 싱글톤이 앱에 없는지 확인합니다. 자세한 내용은 범위 유효성 검사를 참조하세요.

모든 권장 사항과 마찬가지로, 권장 사항을 무시해야 하는 상황이 발생할 수 있습니다. 예외는 드물게 발생하며 대부분 프레임워크 자체 내에서 특별한 경우에만 발생합니다.

DI는 정적/전역 개체 액세스 패턴의 ‘대안’입니다. 고정 개체 액세스와 함께 사용할 경우 DI의 장점을 실현할 수 없습니다.

Orchard Core는 ASP.NET Core에서 모듈식 다중 테넌트 애플리케이션을 빌드하기 위한 애플리케이션 프레임워크입니다. 자세한 내용은 Orchard Core 설명서를 참조하세요.

CMS 고유 기능 없이 Orchard Core Framework를 사용하여 모듈식 다중 테넌트 앱을 빌드하는 방법에 대한 예제는 Orchard Core 샘플을 참조하세요.

프레임워크에서 제공하는 서비스

Startup.ConfigureServices 메서드는 Entity Framework Core 및 ASP.NET Core MVC와 같은 플랫폼 기능을 비롯해 앱이 사용하는 서비스를 등록합니다. 처음에 ConfigureServices에 제공되는 IServiceCollection에는 호스트가 구성된 방법에 따라 달라지는 프레임워크에 의해 정의되는 서비스가 있습니다. ASP.NET Core 템플릿을 기반으로 하는 앱의 경우 프레임워크에서 250개 이상의 서비스를 등록합니다.

다음 표에는 프레임워크에서 등록한 서비스들의 작은 샘플이 나열되어 있습니다.

서비스 종류 수명
Microsoft.AspNetCore.Hosting.Builder.IApplicationBuilderFactory 임시
IHostApplicationLifetime Singleton
IWebHostEnvironment Singleton
Microsoft.AspNetCore.Hosting.IStartup Singleton
Microsoft.AspNetCore.Hosting.IStartupFilter 임시
Microsoft.AspNetCore.Hosting.Server.IServer Singleton
Microsoft.AspNetCore.Http.IHttpContextFactory 임시
Microsoft.Extensions.Logging.ILogger<TCategoryName> Singleton
Microsoft.Extensions.Logging.ILoggerFactory Singleton
Microsoft.Extensions.ObjectPool.ObjectPoolProvider Singleton
Microsoft.Extensions.Options.IConfigureOptions<TOptions> 임시
Microsoft.Extensions.Options.IOptions<TOptions> Singleton
System.Diagnostics.DiagnosticSource Singleton
System.Diagnostics.DiagnosticListener Singleton

추가 자료

작성자: Steve Smith, Scott AddieBrandon Dahler

ASP.NET Core는 클래스와 해당 종속성 간의 IoC(Inversion of Control)를 실현하는 기술인 DI(종속성 주입) 소프트웨어 디자인 패턴을 지원합니다.

MVC 컨트롤러 내의 종속성 주입에 대한 자세한 내용은 ASP.NET Core의 컨트롤러에 종속성 주입을 참조하세요.

예제 코드 살펴보기 및 다운로드 (다운로드 방법)

종속성 주입 개요

‘종속성’은 다른 개체에 필요한 모든 개체입니다. 앱의 다른 클래스가 종속된 MyDependency 클래스에서 WriteMessage 메서드를 사용하는 다음 코드를 살펴보세요.

public class MyDependency
{
    public MyDependency()
    {
    }

    public Task WriteMessage(string message)
    {
        Console.WriteLine(
            $"MyDependency.WriteMessage called. Message: {message}");

        return Task.FromResult(0);
    }
}

MyDependency 클래스의 인스턴스를 만들어 클래스에서 WriteMessage 메서드를 사용할 수 있게 할 수 있습니다. MyDependency 클래스는 IndexModel 클래스의 종속성입니다.

public class IndexModel : PageModel
{
    MyDependency _dependency = new MyDependency();

    public async Task OnGetAsync()
    {
        await _dependency.WriteMessage(
            "IndexModel.OnGetAsync created this message.");
    }
}

이 클래스는 MyDependency 인스턴스를 만들고 이 인스턴스에 직접 종속됩니다. 이전 예제와 같은 코드 종속성은 문제가 있으며 다음과 같은 이유로 사용하지 않아야 합니다.

  • MyDependency를 다른 구현으로 바꾸려면 클래스를 수정해야 합니다.
  • MyDependency에 종속성이 있으면 클래스에서 해당 종속성을 구성해야 합니다. 여러 클래스가 MyDependency에 종속되어 있는 대형 프로젝트에서는 구성 코드가 앱 전체에 분산됩니다.
  • 이 구현은 단위 테스트하기가 어렵습니다. 앱에서 모의 또는 스텁 MyDependency 클래스를 사용해야 하지만, 이 방법에서는 가능하지 않습니다.

종속성 주입은 다음을 통해 이러한 문제를 해결합니다.

  • 인퍼테이스 또는 기본 클래스를 사용하여 종속성 구현을 추상화합니다.
  • 서비스 컨테이너에 종속성 등록. ASP.NET Core는 서비스 컨테이너인 IServiceProvider를 기본 제공합니다. 서비스는 앱의 Startup.ConfigureServices 메서드에서 등록됩니다.
  • 서비스가 사용되는 클래스의 생성자에 주입됨. 프레임워크가 종속성의 인스턴스를 만들고 더 이상 필요하지 않으면 삭제하는 작업을 담당합니다.

샘플 앱에서 IMyDependency 인터페이스는 서비스가 앱에 제공하는 메서드를 정의합니다.

public interface IMyDependency
{
    Task WriteMessage(string message);
}

이 인터페이스는 구체적인 형식 MyDependency에서 구현됩니다.

public class MyDependency : IMyDependency
{
    private readonly ILogger<MyDependency> _logger;

    public MyDependency(ILogger<MyDependency> logger)
    {
        _logger = logger;
    }

    public Task WriteMessage(string message)
    {
        _logger.LogInformation(
            "MyDependency.WriteMessage called. Message: {Message}", 
            message);

        return Task.FromResult(0);
    }
}

MyDependency는 자신의 생성자에서 ILogger<TCategoryName>를 요청합니다. 종속성 주입을 연결된 방식으로 사용하는 일은 특별한 경우가 아닙니다. 요청된 각 종속성은 차례로 자체 종속성을 요청합니다. 컨테이너는 그래프의 종속성을 해결하고 완전히 해결된 서비스를 반환합니다. 해결해야 하는 종속성이 모인 집합은 일반적으로 종속성 트리, 종속성 그래프 또는 개체 그래프라고 합니다 .

IMyDependencyILogger<TCategoryName>는 서비스 컨테이너에 등록되어야 합니다. IMyDependencyStartup.ConfigureServices에서 등록됩니다. ILogger<TCategoryName>은 로깅 추상화 인프라에서 등록하므로, 프레임워크에서 기본적으로 등록한 프레임워크 제공 서비스입니다.

컨테이너는 개방형 형식(제네릭)을 활용하여 ILogger<TCategoryName>을 해결하므로 모든 생성된 형식(제네릭)을 등록하지 않아도 됩니다.

services.AddSingleton(typeof(ILogger<>), typeof(Logger<>));

샘플 앱에서 IMyDependency 서비스는 구체적인 형식 MyDependency로 등록됩니다. 이 등록은 서비스 수명을 단일 요청의 수명으로 지정합니다. 서비스 수명에 대해서는 이 항목의 뒷부분에서 설명합니다.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

    services.AddScoped<IMyDependency, MyDependency>();
    services.AddTransient<IOperationTransient, Operation>();
    services.AddScoped<IOperationScoped, Operation>();
    services.AddSingleton<IOperationSingleton, Operation>();
    services.AddSingleton<IOperationSingletonInstance>(new Operation(Guid.Empty));

    // OperationService depends on each of the other Operation types.
    services.AddTransient<OperationService, OperationService>();
}

참고

services.Add{SERVICE_NAME} 확장 메서드는 서비스를 추가하고 잠재적으로 구성합니다. 예를 들어 services.AddControllersWithViews, services.AddRazorPages, services.AddControllers는 앱에 필요한 서비스 ASP.NET Core 앱을 추가합니다. 앱에서 이 규칙을 따르는 것이 좋습니다. 확장 메서드를 Microsoft.Extensions.DependencyInjection 네임스페이스에 배치하여 서비스 등록 그룹을 캡슐화합니다. DI 확장 메서드에 대해 Microsoft.Extensions.DependencyInjection 네임스페이스 부분을 포함하면 다음도 가능합니다.

  • 더 이상의 using 블록을 추가하지 않고도 IntelliSense에 표시할 수 있습니다.
  • 이러한 확장 메서드가 일반적으로 호출되는 Startup 클래스의 과도한 using 문을 방지합니다.

서비스의 생성자에 string과 같은 기본 제공 형식이 필요한 경우 구성옵션 패턴을 사용하여 해당 형식을 삽입할 수 있습니다.

public class MyDependency : IMyDependency
{
    public MyDependency(IConfiguration config)
    {
        var myStringValue = config["MyStringKey"];

        // Use myStringValue
    }

    ...
}

서비스의 인스턴스는 서비스가 사용되는 클래스의 생성자를 통해 요청되고 전용 필드에 할당됩니다. 이 필드는 클래스 전체에서 필요에 따라 서비스에 액세스하는 데 사용됩니다.

샘플 앱에서는 IMyDependency 인스턴스가 요청되며 이 인스턴스는 서비스의 WriteMessage 메서드를 호출하는 데 사용됩니다.

public class IndexModel : PageModel
{
    private readonly IMyDependency _myDependency;

    public IndexModel(
        IMyDependency myDependency, 
        OperationService operationService,
        IOperationTransient transientOperation,
        IOperationScoped scopedOperation,
        IOperationSingleton singletonOperation,
        IOperationSingletonInstance singletonInstanceOperation)
    {
        _myDependency = myDependency;
        OperationService = operationService;
        TransientOperation = transientOperation;
        ScopedOperation = scopedOperation;
        SingletonOperation = singletonOperation;
        SingletonInstanceOperation = singletonInstanceOperation;
    }

    public OperationService OperationService { get; }
    public IOperationTransient TransientOperation { get; }
    public IOperationScoped ScopedOperation { get; }
    public IOperationSingleton SingletonOperation { get; }
    public IOperationSingletonInstance SingletonInstanceOperation { get; }

    public async Task OnGetAsync()
    {
        await _myDependency.WriteMessage(
            "IndexModel.OnGetAsync created this message.");
    }
}

시작에 삽입된 서비스

제네릭 호스트(IHostBuilder)를 사용할 경우 다음 서비스 유형만 Startup 생성자에 삽입할 수 있습니다.

서비스는 Startup.Configure에 삽입할 수 있습니다.

public void Configure(IApplicationBuilder app, IOptions<MyOptions> options)
{
    ...
}

자세한 내용은 ASP.NET Core에서 앱 시작을 참조하세요.

프레임워크에서 제공하는 서비스

Startup.ConfigureServices 메서드는 Entity Framework Core 및 ASP.NET Core MVC와 같은 플랫폼 기능을 비롯해 앱이 사용하는 서비스를 정의합니다. 처음에 ConfigureServices에 제공되는 IServiceCollection에는 호스트가 구성된 방법에 따라 달라지는 프레임워크에 의해 정의되는 서비스가 있습니다. ASP.NET Core 템플릿을 기반으로 하는 앱의 경우 프레임워크에 의해 등록된 수백 개의 서비스를 가지는 것은 드문 일이 아닙니다. 다음 표에는 프레임워크에서 등록한 서비스들의 작은 샘플이 나열되어 있습니다.

서비스 유형 수명
Microsoft.AspNetCore.Hosting.Builder.IApplicationBuilderFactory 임시
Microsoft.AspNetCore.Hosting.IApplicationLifetime Singleton
Microsoft.AspNetCore.Hosting.IHostingEnvironment Singleton
Microsoft.AspNetCore.Hosting.IStartup Singleton
Microsoft.AspNetCore.Hosting.IStartupFilter 임시
Microsoft.AspNetCore.Hosting.Server.IServer Singleton
Microsoft.AspNetCore.Http.IHttpContextFactory 임시
Microsoft.Extensions.Logging.ILogger<TCategoryName> Singleton
Microsoft.Extensions.Logging.ILoggerFactory Singleton
Microsoft.Extensions.ObjectPool.ObjectPoolProvider Singleton
Microsoft.Extensions.Options.IConfigureOptions<TOptions> 임시
Microsoft.Extensions.Options.IOptions<TOptions> Singleton
System.Diagnostics.DiagnosticSource Singleton
System.Diagnostics.DiagnosticListener Singleton

확장 메서드를 사용하여 추가 서비스 등록

서비스 컬렉션 확장 메서드를 사용하여 서비스(및 필요한 경우 해당 종속 서비스)를 등록할 수 있는 경우 단일 Add{SERVICE_NAME} 확장 메서드를 사용하여 해당 서비스에 필요한 모든 서비스를 등록하는 것이 규칙입니다. 다음 코드는 확장 메서드 AddDbContext<TContext>AddIdentityCore를 사용하여 컨테이너에 서비스를 추가하는 방법을 보여 주는 예제입니다.

public void ConfigureServices(IServiceCollection services)
{
    ...

    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

    services.AddIdentity<ApplicationUser, IdentityRole>()
        .AddEntityFrameworkStores<ApplicationDbContext>()
        .AddDefaultTokenProviders();

    ...
}

자세한 내용은 API 설명서의 ServiceCollection 클래스를 참조하세요.

서비스 수명

등록된 각 서비스의 수명을 적절히 선택합니다. ASP.NET Core 서비스는 다음 수명을 사용하여 구성할 수 있습니다.

임시

Transient 수명 서비스(AddTransient)는 서비스 컨테이너에서 요청할 때마다 만들어집니다. 이 수명은 간단한 상태 비저장 서비스에 가장 적합합니다.

요청을 처리하는 앱에서 Transient 서비스는 요청이 끝날 때 삭제됩니다.

Scoped

Scoped 수명 서비스(AddScoped)는 클라이언트 요청(연결)당 한 번 생성됩니다.

요청을 처리하는 앱에서 Scoped 서비스는 요청이 끝날 때 삭제됩니다.

경고

미들웨어에서 범위가 지정된 서비스를 사용하는 경우 Invoke 또는 InvokeAsync 메서드에 서비스를 삽입합니다. 생성자 삽입은 서비스가 singleton처럼 작동하게 하므로 이러한 방법으로 삽입하지 마세요. 자세한 내용은 사용자 지정 ASP.NET Core 미들웨어 작성을 참조하세요.

Singleton

싱글톤 수명 서비스(AddSingleton)는 처음 요청할 때(또는 Startup.ConfigureServices를 실행하고 서비스 등록에서 인스턴스를 지정하는 경우) 생성됩니다. 모든 후속 요청에서는 같은 인스턴스를 사용합니다. 앱에 싱글톤 동작이 필요한 경우 서비스 컨테이너가 서비스 수명을 관리하도록 허용하는 것이 좋습니다. 싱글톤 디자인 패턴을 구현하거나 클래스의 개체 수명을 관리하는 사용자 코드를 제공하지 마세요.

요청을 처리하는 앱에서 Singleton 서비스는 앱 종료 시 ServiceProvider가 삭제될 때 삭제됩니다.

경고

범위가 지정된 서비스를 싱글톤에서 해결하면 위험합니다. 이 경우 후속 요청을 처리할 때 서비스가 잘못된 상태일 수 있습니다.

서비스 등록 메서드

서비스 등록 확장 메서드는 특정 시나리오에 유용한 오버로드를 제공합니다.

메서드 자동
개체
삭제
여러
구현
인수 전달
Add{LIFETIME}<{SERVICE}, {IMPLEMENTATION}>()
예제:
services.AddSingleton<IMyDep, MyDep>();
Add{LIFETIME}<{SERVICE}>(sp => new {IMPLEMENTATION})
예:
services.AddSingleton<IMyDep>(sp => new MyDep());
services.AddSingleton<IMyDep>(sp => new MyDep("A string!"));
Add{LIFETIME}<{IMPLEMENTATION}>()
예제:
services.AddSingleton<MyDep>();
AddSingleton<{SERVICE}>(new {IMPLEMENTATION})
예:
services.AddSingleton<IMyDep>(new MyDep());
services.AddSingleton<IMyDep>(new MyDep("A string!"));
AddSingleton(new {IMPLEMENTATION})
예:
services.AddSingleton(new MyDep());
services.AddSingleton(new MyDep("A string!"));

형식 삭제에 대한 자세한 내용은 서비스의 삭제 섹션을 참조하세요. 여러 구현에 대한 일반적인 시나리오는 테스트용 모의 형식입니다.

구현 형식만으로 서비스를 등록하는 것은 동일한 구현 및 서비스 형식으로 해당 서비스를 등록하는 것과 같습니다. 따라서 명시적 서비스 형식을 사용하지 않는 메서드를 사용하여 서비스의 여러 구현을 등록할 수 없습니다. 이러한 메서드는 서비스의 여러 ‘인스턴스’를 등록할 수 있지만 모두 동일한 ‘구현’ 형식을 사용합니다.

위의 서비스 등록 메서드 중 하나를 사용하여 동일한 서비스 형식의 여러 서비스 인스턴스를 등록할 수 있습니다. 다음 예제에서는 IMyDependency를 서비스 형식으로 사용하여 AddSingleton을 두 번 호출합니다. 두 번째 AddSingleton 호출은 IMyDependency로 확인되면 이전 호출을 재정의하고 IEnumerable<IMyDependency>를 통해 여러 서비스가 확인되면 이전 호출에 추가됩니다. 서비스는 IEnumerable<{SERVICE}>를 통해 해결될 때 등록된 순서로 나타납니다.

services.AddSingleton<IMyDependency, MyDependency>();
services.AddSingleton<IMyDependency, DifferentDependency>();

public class MyService
{
    public MyService(IMyDependency myDependency, 
       IEnumerable<IMyDependency> myDependencies)
    {
        Trace.Assert(myDependency is DifferentDependency);

        var dependencyArray = myDependencies.ToArray();
        Trace.Assert(dependencyArray[0] is MyDependency);
        Trace.Assert(dependencyArray[1] is DifferentDependency);
    }
}

또한 프레임워크에서는 아직 등록된 구현이 없는 경우에만 서비스를 등록하는 TryAdd{LIFETIME} 확장 메서드를 제공합니다.

다음 예제에서 AddSingleton을 호출하면 MyDependencyIMyDependency에 대한 구현으로 등록됩니다. TryAddSingleton 호출은 IMyDependency에 이미 등록된 구현이 있기 때문에 아무런 효과가 없습니다.

services.AddSingleton<IMyDependency, MyDependency>();
// The following line has no effect:
services.TryAddSingleton<IMyDependency, DifferentDependency>();

public class MyService
{
    public MyService(IMyDependency myDependency, 
        IEnumerable<IMyDependency> myDependencies)
    {
        Trace.Assert(myDependency is MyDependency);
        Trace.Assert(myDependencies.Single() is MyDependency);
    }
}

자세한 내용은 다음을 참조하세요.

TryAddEnumerable(ServiceDescriptor) 메서드는 동일한 형식 의 구현이 아직 없는 경우에만 서비스를 등록합니다. 여러 서비스가 IEnumerable<{SERVICE}>를 통해 해결됩니다. 서비스를 등록할 때 개발자는 동일한 유형 중 하나가 아직 추가되지 않은 경우에만 인스턴스를 추가하려고 합니다. 일반적으로 이 메서드는 라이브러리 작성자가 컨테이너에 두 개 복사본을 등록하지 않도록 하기 위해 사용됩니다.

다음 예제에서 첫 번째 줄은 IMyDep1에 대한 MyDep를 등록합니다. 두 번째 줄은 IMyDep2에 대한 MyDep를 등록합니다. 세 번째 줄은 IMyDep1에 이미 MyDep의 등록된 구현이 이미 있으므로 아무런 효과가 없습니다.

public interface IMyDep1 {}
public interface IMyDep2 {}

public class MyDep : IMyDep1, IMyDep2 {}

services.TryAddEnumerable(ServiceDescriptor.Singleton<IMyDep1, MyDep>());
services.TryAddEnumerable(ServiceDescriptor.Singleton<IMyDep2, MyDep>());
// Two registrations of MyDep for IMyDep1 is avoided by the following line:
services.TryAddEnumerable(ServiceDescriptor.Singleton<IMyDep1, MyDep>());

생성자 주입 동작

다음 두 가지 메커니즘으로 서비스를 해결할 수 있습니다.

  • IServiceProvider
  • ActivatorUtilities: 종속성 주입 컨테이너에 서비스 등록 없이 개체를 생성할 수 있습니다. ActivatorUtilities는 태그 도우미, MVC 컨트롤러 및 모델 바인더와 같은 사용자용 추상화에 사용됩니다.

생성자에는 종속성 주입으로 제공되지 않는 인수를 사용할 수 있지만, 인수에 기본값을 할당해야 합니다.

IServiceProvider 또는 ActivatorUtilities로 서비스를 해결하는 경우 생성자 주입public 생성자가 필요합니다.

ActivatorUtilities로 서비스를 해결하는 경우 생성자 주입을 위해서는 적합한 생성자가 하나만 있어야 합니다. 생성자 오버로드가 지원되지만, 해당 인수가 모두 종속성 주입으로 처리될 수 있는 하나의 오버로드만 존재할 수 있습니다.

Entity Framework 컨텍스트

Entity Framework 컨텍스트는 일반적으로 범위가 지정된 수명을 사용하여 서비스 컨테이너에 추가됩니다. 이는 웹앱 데이터베이스 작업이 일반적으로 클라이언트 요청에 따라 범위가 지정되기 때문입니다. 데이터베이스 컨텍스트를 등록할 때 AddDbContext<TContext> 오버로드로 수명을 지정하지 않으면 기본 수명으로 수명 범위가 지정됩니다. 지정된 수명의 서비스는 서비스보다 수명이 짧은 데이터베이스 컨텍스트를 사용해서는 안됩니다.

수명 및 등록 옵션

이러한 수명 및 등록 옵션 간의 차이점을 살펴보려면 작업을 고유한 ID인 OperationId가 부여된 작업으로 나타내는 다음 인터페이스들을 고려해 보세요. 다음 인터페이스들에 대해 작업 서비스의 수명을 구성하는 방법에 따라 컨테이너는 클래스에서 요청할 때 서비스의 같은 인스턴스나 다른 인스턴스를 제공합니다.

public interface IOperation
{
    Guid OperationId { get; }
}

public interface IOperationTransient : IOperation
{
}

public interface IOperationScoped : IOperation
{
}

public interface IOperationSingleton : IOperation
{
}

public interface IOperationSingletonInstance : IOperation
{
}

인터페이스들은 Operation 클래스에서 구현됩니다. Operation 생성자는 GUID가 제공되지 않는 경우 GUID를 생성합니다.

public class Operation : IOperationTransient, 
    IOperationScoped, 
    IOperationSingleton, 
    IOperationSingletonInstance
{
    public Operation() : this(Guid.NewGuid())
    {
    }

    public Operation(Guid id)
    {
        OperationId = id;
    }

    public Guid OperationId { get; private set; }
}

OperationService는 각각 다른 Operation 형식에 종속되어 등록됩니다. 종속성 주입을 통해 OperationService를 요청하면 종속 서비스의 수명에 따라 각 서비스의 새 인스턴스나 기존 인스턴스를 받습니다.

  • 컨테이너에서 요청할 때 임시 서비스가 생성되면 IOperationTransient 서비스의 OperationIdOperationServiceOperationId와 다릅니다. OperationServiceIOperationTransient 클래스의 새 인스턴스를 받습니다. 새 인스턴스는 다른 OperationId를 생성합니다.
  • 클라이언트 요청에 따라 범위가 지정된 서비스가 생성되면 IOperationScoped 서비스의 OperationId는 클라이언트 요청 내의 OperationService와 같습니다. 전체 클라이언트 요청에서 두 서비스는 다른 OperationId 값을 공유합니다.
  • 싱글톤 및 싱글톤 인스턴스 서비스가 한 번 생성되어 모든 클라이언트 요청 및 모든 서비스에서 사용될 경우 OperationId는 모든 서비스 요청에서 동일합니다.
public class OperationService
{
    public OperationService(
        IOperationTransient transientOperation,
        IOperationScoped scopedOperation,
        IOperationSingleton singletonOperation,
        IOperationSingletonInstance instanceOperation)
    {
        TransientOperation = transientOperation;
        ScopedOperation = scopedOperation;
        SingletonOperation = singletonOperation;
        SingletonInstanceOperation = instanceOperation;
    }

    public IOperationTransient TransientOperation { get; }
    public IOperationScoped ScopedOperation { get; }
    public IOperationSingleton SingletonOperation { get; }
    public IOperationSingletonInstance SingletonInstanceOperation { get; }
}

Startup.ConfigureServices에서 각 형식이 자신의 명명된 수명에 따라 컨테이너에 추가됩니다.

public void ConfigureServices(IServiceCollection services)
{
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

    services.AddScoped<IMyDependency, MyDependency>();
    services.AddTransient<IOperationTransient, Operation>();
    services.AddScoped<IOperationScoped, Operation>();
    services.AddSingleton<IOperationSingleton, Operation>();
    services.AddSingleton<IOperationSingletonInstance>(new Operation(Guid.Empty));

    // OperationService depends on each of the other Operation types.
    services.AddTransient<OperationService, OperationService>();
}

IOperationSingletonInstance 서비스는 알려진 ID가 Guid.Empty인 특정 인스턴스를 사용 중입니다. 이 형식이 사용 중임을 명확하게 알 수 있습니다(이 인스턴스의 GUID는 모두 0입니다).

이 샘플 앱은 개별 요청 내의 개체 수명과 개별 요청 간의 개체 수명을 보여 줍니다. 샘플 앱의 IndexModel은 각 종류의 IOperation 형식과 OperationService를 요청합니다. 그런 다음, 페이지에서는 속성 할당을 통해 페이지 모델 클래스 및 서비스의 OperationId 값을 모두 표시합니다.

public class IndexModel : PageModel
{
    private readonly IMyDependency _myDependency;

    public IndexModel(
        IMyDependency myDependency, 
        OperationService operationService,
        IOperationTransient transientOperation,
        IOperationScoped scopedOperation,
        IOperationSingleton singletonOperation,
        IOperationSingletonInstance singletonInstanceOperation)
    {
        _myDependency = myDependency;
        OperationService = operationService;
        TransientOperation = transientOperation;
        ScopedOperation = scopedOperation;
        SingletonOperation = singletonOperation;
        SingletonInstanceOperation = singletonInstanceOperation;
    }

    public OperationService OperationService { get; }
    public IOperationTransient TransientOperation { get; }
    public IOperationScoped ScopedOperation { get; }
    public IOperationSingleton SingletonOperation { get; }
    public IOperationSingletonInstance SingletonInstanceOperation { get; }

    public async Task OnGetAsync()
    {
        await _myDependency.WriteMessage(
            "IndexModel.OnGetAsync created this message.");
    }
}

다음 출력은 두 요청의 결과를 보여 줍니다.

첫 번째 요청: :

컨트롤러 작업:

Transient: d233e165-f417-469b-a866-1cf1935d2518
Scoped: 5d997e2d-55f5-4a64-8388-51c4e3a1ad19
Singleton: 01271bc1-9e31-48e7-8f7c-7261b040ded9
인스턴스: 00000000-0000-0000-0000-000000000000

OperationService 작업:

Transient: c6b049eb-1318-4e31-90f1-eb2dd849ff64
Scoped: 5d997e2d-55f5-4a64-8388-51c4e3a1ad19
Singleton: 01271bc1-9e31-48e7-8f7c-7261b040ded9
인스턴스: 00000000-0000-0000-0000-000000000000

두 번째 요청:

컨트롤러 작업:

Transient: b63bd538-0a37-4ff1-90ba-081c5138dda0
Scoped: 31e820c5-4834-4d22-83fc-a60118acb9f4
Singleton: 01271bc1-9e31-48e7-8f7c-7261b040ded9
인스턴스: 00000000-0000-0000-0000-000000000000

OperationService 작업:

Transient: c4cbacb8-36a2-436d-81c8-8c1b78808aaf
Scoped: 31e820c5-4834-4d22-83fc-a60118acb9f4
Singleton: 01271bc1-9e31-48e7-8f7c-7261b040ded9
인스턴스: 00000000-0000-0000-0000-000000000000

어떤 OperationId 값이 요청 내에서 그리고 요청 간에 달라지는지 확인합니다.

  • Transient 개체는 항상 다릅니다. 첫 번째와 두 번째 클라이언트 요청에 대한 임시 OperationId 값은 OperationService 작업과 클라이언트 요청 간에 모두 다릅니다. 각 서비스 요청과 클라이언트 요청에 새 인스턴스가 제공됩니다.
  • Scoped 개체는 클라이언트 요청 내에서는 동일하지만 클라이언트 요청 간에는 다릅니다.
  • Singleton 개체는 Startup.ConfigureServices에서 Operation 인스턴스 제공 여부와 관계없이 모든 개체 및 모든 요청에 대해 동일합니다.

Main에서 서비스 호출

IServiceScopeFactory.CreateScope를 사용하여 IServiceScope를 만들어서 앱 범위 내로 범위가 지정된 서비스를 해결합니다. 이 방법은 시작 시 범위가 지정된 서비스에 액세스하여 알맞은 서비스 수명과 함께 초기화 작업을 실행하는데 유용합니다. 다음 예제에서는 Program.Main에서 MyScopedService에 대한 컨텍스트를 가져오는 방법을 보여 줍니다.

using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Logging;

public class Program
{
    public static async Task Main(string[] args)
    {
        var host = CreateWebHostBuilder(args).Build();

        using (var serviceScope = host.Services.CreateScope())
        {
            var services = serviceScope.ServiceProvider;

            try
            {
                var serviceContext = services.GetRequiredService<MyScopedService>();
                // Use the context here
            }
            catch (Exception ex)
            {
                var logger = services.GetRequiredService<ILogger<Program>>();
                logger.LogError(ex, "An error occurred.");
            }
        }

        await host.RunAsync();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>();
}

이전 예제에서 ILogger을 비롯하여 임시 서비스에 대한 범위를 만들 필요는 없습니다(참조: .NET Core 및 ASP.NET Core의 로깅). Transients는 범위가 지정된 서비스로서 루트에서 해결되면 부주의하게 단일 데이터베이스로 확인하지 않습니다. Transients은 요청될 때 생성됩니다. Transient 서비스를 삭제 가능한 때가 되면, 삭제될 때까지 컨테이너에 의해 루트됩니다. 예제는 ASP.NET Core에서 IHttpClientFactory를 사용하여 HTTP 요청 만들기을 참조하세요.

범위 유효성 검사

앱이 개발 환경에서 실행 중인 경우 기본 서비스 공급자가 다음을 확인하는 검사를 수행합니다.

  • '직접으로' in current translation is awkward/inappropriate in terms of grammar.
  • 범위가 지정된 서비스는 직접 또는 간접적으로 싱글톤에 삽입되지 않습니다.

루트 서비스 공급자는 BuildServiceProvider를 호출할 때 만들어집니다. 루트 서비스 공급자의 수명은 공급자가 앱과 함께 시작되고 앱이 종료될 때 삭제되는 앱/서버의 수명에 해당합니다.

범위가 지정된 서비스는 서비스를 만든 컨테이너에 의해 삭제됩니다. 범위가 지정된 서비스가 루트 컨테이너에서 만들어지는 경우 서비스의 수명은 사실상 싱글톤으로 승격됩니다. 해당 서비스는 앱/서버가 종료될 때 루트 컨테이너에 의해서만 삭제되기 때문입니다. 서비스 범위의 유효성 검사는 BuildServiceProvider가 호출될 경우 이러한 상황을 감지합니다.

자세한 내용은 ASP.NET Core 웹 호스트을 참조하세요.

요청 서비스

HttpContext의 ASP.NET Core 요청 내에서 사용할 수 있는 서비스는 HttpContext.RequestServices 컬렉션을 통해 노출됩니다.

요청 서비스는 앱의 일부로 구성 및 요청된 서비스를 나타냅니다. 개체가 종속성을 지정한 경우에는 ApplicationServices가 아닌 RequestServices에 있는 형식으로 충족됩니다.

일반적으로 앱은 이러한 속성을 직접 사용해서는 안 됩니다. 대신 클래스 생성자를 통해 클래스에 필요한 형식을 요청하고 프레임워크가 종속성을 주입하도록 합니다. 이 방법이 테스트하기 쉬운 클래스를 생성합니다.

참고

RequestServices 컬렉션에 액세스하는 것보다 생성자 매개 변수로 종속성을 요청하는 것을 선호합니다.

종속성 주입을 위한 서비스 디자인

모범 사례는 다음과 같습니다.

  • 종속성 주입을 사용하여 종속성을 가져오도록 서비스를 디자인합니다.
  • 상태 저장 정적 클래스 및 멤버를 사용하지 마세요. 대신 singleton 서비스를 사용하여 전역 상태를 만들지 않도록 앱을 디자인합니다.
  • 서비스 내의 종속 클래스를 직접 인스턴스화하지 마세요. 직접 인스턴스화는 코드를 특정 구현에 결합합니다.
  • 앱 클래스를 작고 잘 구성되고 쉽게 테스트할 수 있도록 만듭니다.

클래스에 주입된 종속성이 너무 많아 보이면 일반적으로 클래스에 역할이 너무 많고 SRP(단일 책임 원칙)를 위반하는 것일 수 있습니다. 해당 책임 몇 가지를 새로운 클래스로 이동하여 클래스를 리팩터링해 보세요. Razor Pages의 페이지 모델 클래스 및 MVC 컨트롤러 클래스는 UI 고려 사항에 집중해야 합니다. 비즈니스 규칙 및 데이터 액세스 구현 세부 정보는 이러한 문제의 분리에 적합한 클래스에 유지되어야 합니다.

서비스 삭제

컨테이너는 자신이 만든 IDisposable 형식에 대해 Dispose를 호출합니다. 인스턴스가 사용자 코드로 컨테이너에 추가된 경우에는 자동으로 삭제되지 않습니다.

다음 예제에서는 서비스가 서비스 컨테이너에 의해 만들어지고 자동으로 삭제됩니다.

public class Service1 : IDisposable {}
public class Service2 : IDisposable {}

public interface IService3 {}
public class Service3 : IService3, IDisposable {}

public void ConfigureServices(IServiceCollection services)
{
    services.AddScoped<Service1>();
    services.AddSingleton<Service2>();
    services.AddSingleton<IService3>(sp => new Service3());
}

다음 예제에서는

  • 서비스 인스턴스가 서비스 컨테이너에 의해 만들어지지 않습니다.
  • 의도된 서비스 수명을 프레임워크가 알지 못합니다.
  • 프레임워크가 서비스를 자동으로 삭제하지 않습니다.
  • 개발자 코드에서 서비스가 명시적으로 삭제되지 않을 경우 해당 서비스는 앱이 종료될 때까지 유지됩니다.
public class Service1 : IDisposable {}
public class Service2 : IDisposable {}

public void ConfigureServices(IServiceCollection services)
{
    services.AddSingleton<Service1>(new Service1());
    services.AddSingleton(new Service2());
}

임시 및 공유 인스턴스에 대한 IDisposable 지침

임시적인 제한 수명

시나리오

앱에는 다음 시나리오 중 하나에 대해 임시 수명으로 IDisposable 인스턴스가 필요합니다.

  • 인스턴스는 루트 범위에서 확인됩니다.
  • 범위가 끝나기 전에 인스턴스를 삭제해야 합니다.

해결 방법

부모 범위 밖에서 인스턴스를 생성하려면 팩터리 패턴을 사용합니다. 이 경우 앱에는 일반적으로 최종 형식의 생성자를 직접 호출하는 Create 메서드가 있습니다. 최종 형식에 다른 종속성이 있는 경우 팩터리는 다음을 수행할 수 있습니다.

공유 인스턴스 및 제한 수명

시나리오

앱은 여러 서비스에서 공유 IDisposable 인스턴스가 필요하지만 IDisposable는 수명이 제한되어 있어야 합니다.

해결 방법

인스턴스를 범위가 지정된 수명으로 등록합니다. IServiceScopeFactory.CreateScope를 사용하여 시작하고 새로운 IServiceScope를 생성합니다. 범위의 IServiceProvider를 사용하여 필요한 서비스를 가져옵니다. 수명을 종료해야 하는 경우 범위를 삭제합니다.

일반 지침

  • 임시 범위에 IDisposable 인스턴스를 등록하지 마세요. 대신 팩터리 패턴을 사용합니다.
  • 루트 범위에서 임시 또는 범위가 지정된 IDisposable 인스턴스를 확인하지 마세요. 일반적으로 유일한 예외는 앱이 이상적 패턴이 아닌 IServiceProvider를 생성/재생성 및 삭제하는 경우입니다.
  • DI를 통한 IDisposable 종속성 수신은 수신자가 자체적으로 IDisposable를 구현할 필요가 없습니다. IDisposable 종속성의 수신자는 해당 종속성에서 Dispose를 호출하지 않아야 합니다.
  • 범위는 서비스의 수명을 제어하는 데 사용되어야 합니다. 범위는 계층적이지 않으며 범위 간 특수 연결이 없습니다.

기본 서비스 컨테이너 바꾸기

기본 제공 서비스 컨테이너는 프레임워크 및 대부분의 소비자 앱의 요구를 충족하기 위한 것입니다. 기본 제공 컨테이너가 지원하지 않는 특정 기능이 필요하지 않는 한, 다음과 같은 기본 제공 컨테이너를 사용하는 것이 좋습니다.

  • 속성 삽입
  • 이름에 기반한 삽입
  • 자식 컨테이너
  • 사용자 지정 수명 관리
  • 초기화 지연에 대한 Func<T> 지원
  • 규칙 기반 등록

ASP.NET Core 앱에서 사용할 수 있는 타사 컨테이너는 다음과 같습니다.

스레드로부터의 안전성

스레드로부터 안전한 싱글톤 서비스를 만듭니다. 싱글톤 서비스가 Transient 서비스에 대한 종속성을 갖는 경우 Transient 서비스는 싱글톤에서 사용되는 방식에 따라 스레드로부터 안전성이 필요할 수 있습니다.

AddSingleton<TService>(IServiceCollection, Func<IServiceProvider,TService>)의 두 번째 인수와 같은 단일 서비스의 팩터리 메서드는 스레드로부터 안전하지 않아도 됩니다. 형식(static) 생성자와 같이 이 메서드는 단일 스레드에서 한 번만 호출됩니다.

권장 사항

  • async/awaitTask 기반 서비스 해결은 지원되지 않습니다. C#은 비동기 생성자를 지원하지 않으므로, 서비스를 동기식으로 해결한 후 비동기 메서드를 사용하는 패턴이 좋습니다.

  • 데이터 및 구성을 서비스 컨테이너에 직접 저장하지 마세요. 예를 들어 사용자의 쇼핑 카트는 일반적으로 서비스 컨테이너에 추가하지 말아야 합니다. 구성은 옵션 패턴을 사용해야 합니다. 마찬가지로 다른 일부 개체에 대한 액세스를 허용하기 위해서만 존재하는 “데이터 보유자” 개체를 사용하지 마십시오. DI를 통해 실제 항목을 요청하는 것이 좋습니다.

  • 서비스에 정적 액세스를 사용하지 마십시오. 예를 들어 다른 곳에 사용하기 위해 IApplicationBuilder.ApplicationServices를 정적으로 입력하지 마세요.

  • ‘서비스 로케이터 패턴’은 Inversion of Control 전략을 혼합하므로 사용하지 마세요.

    • DI를 대신 사용할 수 있는 경우에는 GetService를 호출하여 서비스 인스턴스를 가져오지 마세요.

      잘못된 예:

      public class MyClass()
      
        public void MyMethod()
        {
            var optionsMonitor = 
                _services.GetService<IOptionsMonitor<MyOptions>>();
            var option = optionsMonitor.CurrentValue.Option;
      
            ...
        }
      

      올바른 예:

      public class MyClass
      {
          private readonly IOptionsMonitor<MyOptions> _optionsMonitor;
      
          public MyClass(IOptionsMonitor<MyOptions> optionsMonitor)
          {
              _optionsMonitor = optionsMonitor;
          }
      
          public void MyMethod()
          {
              var option = _optionsMonitor.CurrentValue.Option;
      
              ...
          }
      }
      
  • 런타임에 GetService를 종속성을 확인하는 팩토리를 삽입하지 마세요.

  • HttpContext(예: IHttpContextAccessor.HttpContext)에 정적으로 액세스하지 마세요.

모든 권장 사항과 마찬가지로, 권장 사항을 무시해야 하는 상황이 발생할 수 있습니다. 예외는 드물게 발생하며 대부분 프레임워크 자체 내에서 특별한 경우에만 발생합니다.

DI는 정적/전역 개체 액세스 패턴의 ‘대안’입니다. 고정 개체 액세스와 함께 사용할 경우 DI의 장점을 실현할 수 없습니다.

추가 리소스