ASP.NET Core에서 종속성 주입Dependency injection in ASP.NET Core

작성자: Kirk Larkin, Steve Smith, Scott AddieBrandon DahlerBy Kirk Larkin, Steve Smith, Scott Addie, and Brandon Dahler

ASP.NET Core는 클래스와 해당 종속성 간의 IoC(Inversion of Control)를 실현하는 기술인 DI(종속성 주입) 소프트웨어 디자인 패턴을 지원합니다.ASP.NET Core supports the dependency injection (DI) software design pattern, which is a technique for achieving Inversion of Control (IoC) between classes and their dependencies.

MVC 컨트롤러 내의 종속성 주입에 대한 자세한 내용은 ASP.NET Core의 컨트롤러에 종속성 주입을 참조하세요.For more information specific to dependency injection within MVC controllers, see ASP.NET Core의 컨트롤러에 종속성 주입.

웹앱이 아닌 애플리케이션에서 종속성 주입을 사용하는 방법에 대한 자세한 내용은 .NET의 종속성 주입을 참조하세요.For information on using dependency injection in applications other than web apps, see Dependency injection in .NET.

옵션의 종속성 주입에 대한 자세한 내용은 ASP.NET Core의 옵션 패턴를 참조하세요.For more information on dependency injection of options, see ASP.NET Core의 옵션 패턴.

이 항목에서는 ASP.NET Core의 종속성 삽입에 관한 정보를 제공합니다.This topic provides information on dependency injection in ASP.NET Core. 종속성 주입 사용에 대한 기본 설명서는 .NET의 종속성 주입에 포함되어 있습니다.The primary documentation on using dependency injection is contained in Dependency injection in .NET.

예제 코드 살펴보기 및 다운로드 (다운로드 방법)View or download sample code (how to download)

종속성 주입 개요Overview of dependency injection

‘종속성’은 다른 개체가 종속된 개체입니다.A dependency is an object that another object depends on. 다른 클래스가 종속된 MyDependency 클래스에서 WriteMessage 메서드를 사용하는 다음 코드를 살펴보세요.Examine the following MyDependency class with a WriteMessage method that other classes depend on:

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

클래스에서 MyDependency 클래스의 인스턴스를 만들어 WriteMessage 메서드를 사용할 수 있습니다.A class can create an instance of the MyDependency class to make use of its WriteMessage method. 다음 예제에서 MyDependency 클래스는 IndexModel 클래스의 종속성입니다.In the following example, the MyDependency class is a dependency of the IndexModel class:

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

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

이 클래스는 MyDependency 클래스를 만들고 이 클래스에 직접 종속됩니다.The class creates and directly depends on the MyDependency class. 이전 예제와 같은 코드 종속성은 문제가 있으며 다음과 같은 이유로 사용하지 않아야 합니다.Code dependencies, such as in the previous example, are problematic and should be avoided for the following reasons:

  • MyDependency를 다른 구현으로 바꾸려면 IndexModel 클래스를 수정해야 합니다.To replace MyDependency with a different implementation, the IndexModel class must be modified.
  • MyDependency에 종속성이 있으면 IndexModel 클래스에서 해당 종속성도 구성해야 합니다.If MyDependency has dependencies, they must also be configured by the IndexModel class. 여러 클래스가 MyDependency에 종속되어 있는 대형 프로젝트에서는 구성 코드가 앱 전체에 분산됩니다.In a large project with multiple classes depending on MyDependency, the configuration code becomes scattered across the app.
  • 이 구현은 단위 테스트하기가 어렵습니다.This implementation is difficult to unit test. 앱에서 모의 또는 스텁 MyDependency 클래스를 사용해야 하지만, 이 방법에서는 가능하지 않습니다.The app should use a mock or stub MyDependency class, which isn't possible with this approach.

종속성 주입은 다음을 통해 이러한 문제를 해결합니다.Dependency injection addresses these problems through:

  • 인퍼테이스 또는 기본 클래스를 사용하여 종속성 구현을 추상화합니다.The use of an interface or base class to abstract the dependency implementation.
  • 서비스 컨테이너에 종속성 등록.Registration of the dependency in a service container. ASP.NET Core는 서비스 컨테이너인 IServiceProvider를 기본 제공합니다.ASP.NET Core provides a built-in service container, IServiceProvider. 서비스는 일반적으로 앱의 Startup.ConfigureServices 메서드에서 등록됩니다.Services are typically registered in the app's Startup.ConfigureServices method.
  • 서비스가 사용되는 클래스의 생성자에 주입됨.Injection of the service into the constructor of the class where it's used. 프레임워크가 종속성의 인스턴스를 만들고 더 이상 필요하지 않으면 삭제하는 작업을 담당합니다.The framework takes on the responsibility of creating an instance of the dependency and disposing of it when it's no longer needed.

샘플 앱에서 IMyDependency 인터페이스는 WriteMessage 메서드를 정의합니다.In the sample app, the IMyDependency interface defines the WriteMessage method:

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

이 인터페이스는 구체적인 형식 MyDependency에서 구현됩니다.This interface is implemented by a concrete type, MyDependency:

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

샘플 앱에서는 IMyDependency 서비스를 구체적인 MyDependency 형식으로 등록합니다.The sample app registers the IMyDependency service with the concrete type MyDependency. AddScoped 메서드는 단일 요청의 수명인 범위가 지정된 수명으로 서비스를 등록합니다.The AddScoped method registers the service with a scoped lifetime, the lifetime of a single request. 서비스 수명에 대해서는 이 항목의 뒷부분에서 설명합니다.Service lifetimes are described later in this topic.

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

    services.AddRazorPages();
}

샘플 앱에서는 IMyDependency 서비스가 요청되며 이 서비스는 WriteMessage 메서드를 호출하는 데 사용됩니다.In the sample app, the IMyDependency service is requested and used to call the WriteMessage method:

public class Index2Model : PageModel
{
    private readonly IMyDependency _myDependency;

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

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

DI 패턴을 사용하여 컨트롤러는 다음을 수행합니다.By using the DI pattern, the controller:

  • 컨트롤러는 구체적인 형식 MyDependency를 사용하지 않고 구현되는 IMyDependency 인터페이스만 사용합니다.Doesn't use the concrete type MyDependency, only the IMyDependency interface it implements. 따라서 컨트롤러에서 사용하는 구현을 컨트롤러를 수정하지 않고 쉽게 변경할 수 있습니다.That makes it easy to change the implementation that the controller uses without modifying the controller.
  • MyDependency의 인스턴스를 만들지 않습니다. 해당 인스턴스는 DI 컨테이너에 의해 만들어집니다.Doesn't create an instance of MyDependency, it's created by the DI container.

IMyDependency 인터페이스의 구현을 기본 제공 로깅 API를 사용하여 향상할 수 있습니다.The implementation of the IMyDependency interface can be improved by using the built-in logging 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 구현을 등록합니다.The updated ConfigureServices method registers the new IMyDependency implementation:

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

    services.AddRazorPages();
}

MyDependency2는 생성자에서 요청하는 ILogger<TCategoryName>에 종속됩니다.MyDependency2 depends on ILogger<TCategoryName>, which it requests in the constructor. ILogger<TCategoryName>프레임워크에서 제공하는 서비스입니다.ILogger<TCategoryName> is a framework-provided service.

종속성 주입을 연결된 방식으로 사용하는 일은 특별한 경우가 아닙니다.It's not unusual to use dependency injection in a chained fashion. 요청된 각 종속성은 차례로 자체 종속성을 요청합니다.Each requested dependency in turn requests its own dependencies. 컨테이너는 그래프의 종속성을 해결하고 완전히 해결된 서비스를 반환합니다.The container resolves the dependencies in the graph and returns the fully resolved service. 해결해야 하는 종속성이 모인 집합은 일반적으로 종속성 트리, 종속성 그래프 또는 개체 그래프라고 합니다 .The collective set of dependencies that must be resolved is typically referred to as a dependency tree, dependency graph, or object graph.

컨테이너는 개방형 형식(제네릭)을 활용하여 ILogger<TCategoryName>을 해결하므로 모든 생성된 형식(제네릭)을 등록하지 않아도 됩니다.The container resolves ILogger<TCategoryName> by taking advantage of (generic) open types, eliminating the need to register every (generic) constructed type.

종속성 주입 용어에서 서비스는 다음과 같습니다.In dependency injection terminology, a service:

  • 일반적으로 다른 개체에 IMyDependency 서비스와 같은 서비스를 제공하는 개체입니다.Is typically an object that provides a service to other objects, such as the IMyDependency service.
  • 서비스에서 웹 서비스를 사용할 수 있지만 웹 서비스와 관련 있는 것은 아닙니다.Is not related to a web service, although the service may use a web service.

해당 프레임워크는 강력한 로깅 시스템을 제공합니다.The framework provides a robust logging system. 이전 예제에 표시된 IMyDependency 구현은 로깅을 구현하는 것이 아니라 기본 DI를 보여 주기 위해 작성되었습니다.The IMyDependency implementations shown in the preceding examples were written to demonstrate basic DI, not to implement logging. 대부분의 앱에서는 로거를 작성할 필요가 없습니다.Most apps shouldn't need to write loggers. 다음 코드에서는 ConfigureServices에 서비스를 등록하지 않아도 되는 기본 로깅을 사용하는 방법을 보여 줍니다.The following code demonstrates using the default logging, which doesn't require any services to be registered in 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를 업데이트할 필요가 없습니다.Using the preceding code, there is no need to update ConfigureServices, because logging is provided by the framework.

시작에 삽입된 서비스Services injected into Startup

서비스를 Startup 생성자 및 Startup.Configure 메서드에 삽입할 수 있습니다.Services can be injected into the Startup constructor and the Startup.Configure method.

제네릭 호스트(IHostBuilder)를 사용할 경우 다음 서비스 유형만 Startup 생성자에 삽입할 수 있습니다.Only the following services can be injected into the Startup constructor when using the Generic Host (IHostBuilder):

DI 컨테이너에 등록된 모든 서비스를 Startup.Configure 메서드에 삽입할 수 있습니다.Any service registered with the DI container can be injected into the Startup.Configure method:

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

자세한 내용은 ASP.NET Core에서 앱 시작시작 시 구성 액세스를 참조하세요.For more information, see ASP.NET Core에서 앱 시작 and Access configuration in Startup.

확장 메서드를 사용하여 서비스 그룹 등록Register groups of services with extension methods

ASP.NET Core 프레임워크에서는 관련 서비스 그룹을 등록하는 규칙을 사용합니다.The ASP.NET Core framework uses a convention for registering a group of related services. 규칙은 단일 Add{GROUP_NAME} 확장 메서드를 사용하여 프레임워크 기능에 필요한 모든 서비스를 등록하는 것입니다.The convention is to use a single Add{GROUP_NAME} extension method to register all of the services required by a framework feature. 예를 들어 AddControllers 확장 메서드는 MVC 컨트롤러에 필요한 서비스를 등록합니다.For example, the AddControllers extension method registers the services required for MVC controllers.

다음 코드는 개별 사용자 계정을 사용하는 Razor Pages 템플릿으로 생성되며 확장 메서드 AddDbContextAddDefaultIdentity를 사용하여 컨테이너에 서비스를 추가하는 방법을 보여 줍니다.The following code is generated by the Razor Pages template using individual user accounts and shows how to add additional services to the container using the extension methods AddDbContext and AddDefaultIdentity:

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 메서드를 고려합니다.Consider the following ConfigureServices method, which registers services and configures options:

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();
}

관련 등록 그룹을 확장 메서드로 이동하여 서비스를 등록할 수 있습니다.Related groups of registrations can be moved to an extension method to register services. 예를 들어, 구성 서비스는 다음 클래스에 추가됩니다.For example, the configuration services are added to the following class:

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;
        }
    }
}

나머지 서비스는 유사한 클래스에 등록됩니다.The remaining services are registered in a similar class. 다음 ConfigureServices 메서드는 새 확장 메서드를 사용하여 서비스를 등록합니다.The following ConfigureServices method uses the new extension methods to register the services:

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

    services.AddRazorPages();
}

참고:services.Add{GROUP_NAME} 확장 메서드는 서비스를 추가하고 잠재적으로 구성합니다.Note: Each services.Add{GROUP_NAME} extension method adds and potentially configures services. 예를 들어 AddControllersWithViews는 보기에 필요한 서비스 MVC 컨트롤러를 추가하고 AddRazorPages는 Razor Pages에 필요한 서비스를 추가합니다.For example, AddControllersWithViews adds the services MVC controllers with views require, and AddRazorPages adds the services Razor Pages requires. 앱에서 이 명명 규칙을 따르는 것이 좋습니다.We recommended that apps follow this naming convention. 확장 메서드를 Microsoft.Extensions.DependencyInjection 네임스페이스에 배치하여 서비스 등록 그룹을 캡슐화합니다.Place extension methods in the Microsoft.Extensions.DependencyInjection namespace to encapsulate groups of service registrations.

서비스 수명Service lifetimes

.NET의 종속성 주입서비스 수명을 참조하세요.See Service lifetimes in Dependency injection in .NET

미들웨어에서 범위 지정 서비스를 사용하려면 다음 방법 중 하나를 사용합니다.To use scoped services in middleware, use one of the following approaches:

  • 미들웨어의 Invoke 또는 InvokeAsync 메서드에 서비스를 삽입합니다.Inject the service into the middleware's Invoke or InvokeAsync method. 생성자 주입을 사용하면 범위 지정 서비스가 싱글톤처럼 작동하게 하므로 런타임 예외가 throw됩니다.Using constructor injection throws a runtime exception because it forces the scoped service to behave like a singleton. 수명 및 등록 옵션 섹션의 샘플에서는 InvokeAsync 방법을 보여 줍니다.The sample in the Lifetime and registration options section demonstrates the InvokeAsync approach.
  • 팩터리 기반 미들웨어를 사용합니다.Use Factory-based middleware. 이 방법을 사용하여 등록된 미들웨어는 클라이언트를 요청(연결)할 때마다 활성화되어, 범위 지정 서비스를 미들웨어의 InvokeAsync 메서드에 삽입할 수 있도록 해줍니다.Middleware registered using this approach is activated per client request (connection), which allows scoped services to be injected into the middleware's InvokeAsync method.

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

서비스 등록 메서드Service registration methods

.NET의 종속성 주입서비스 등록 메서드를 참조하세요.See Service registration methods in Dependency injection in .NET

테스트를 위한 형식을 모의할 때 여러 구현을 사용하는 것이 일반적입니다.It's common to use multiple implementations when mocking types for testing.

구현 형식만으로 서비스를 등록하는 것은 동일한 구현 및 서비스 형식으로 해당 서비스를 등록하는 것과 같습니다.Registering a service with only an implementation type is equivalent to registering that service with the same implementation and service type. 따라서 명시적 서비스 형식을 사용하지 않는 메서드를 사용하여 서비스의 여러 구현을 등록할 수 없습니다.This is why multiple implementations of a service cannot be registered using the methods that don't take an explicit service type. 이러한 메서드는 서비스의 여러 ‘인스턴스’를 등록할 수 있지만 모두 동일한 ‘구현’ 형식을 사용합니다. These methods can register multiple instances of a service, but they will all have the same implementation type.

위의 서비스 등록 메서드 중 하나를 사용하여 동일한 서비스 형식의 여러 서비스 인스턴스를 등록할 수 있습니다.Any of the above service registration methods can be used to register multiple service instances of the same service type. 다음 예제에서는 IMyDependency를 서비스 형식으로 사용하여 AddSingleton을 두 번 호출합니다.In the following example, AddSingleton is called twice with IMyDependency as the service type. 두 번째 AddSingleton 호출은 IMyDependency로 확인되면 이전 호출을 재정의하고 IEnumerable<IMyDependency>를 통해 여러 서비스가 확인되면 이전 호출에 추가됩니다.The second call to AddSingleton overrides the previous one when resolved as IMyDependency and adds to the previous one when multiple services are resolved via IEnumerable<IMyDependency>. 서비스는 IEnumerable<{SERVICE}>를 통해 해결될 때 등록된 순서로 나타납니다.Services appear in the order they were registered when resolved via 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);
    }
}

생성자 주입 동작Constructor injection behavior

.NET의 종속성 주입생성자 주입 동작을 참조하세요.See Constructor injection behavior in Dependency injection in .NET

Entity Framework 컨텍스트Entity Framework contexts

기본적으로 Entity Framework 컨텍스트는 범위가 지정된 수명을 사용하여 서비스 컨테이너에 추가됩니다. 이는 웹앱 데이터베이스 작업이 일반적으로 클라이언트 요청에 따라 범위가 지정되기 때문입니다.By default, Entity Framework contexts are added to the service container using the scoped lifetime because web app database operations are normally scoped to the client request. 다른 수명을 사용하려면 AddDbContext 오버로드를 사용하여 수명을 지정합니다.To use a different lifetime, specify the lifetime by using an AddDbContext overload. 지정된 수명의 서비스는 서비스보다 수명이 짧은 데이터베이스 컨텍스트를 사용해서는 안됩니다.Services of a given lifetime shouldn't use a database context with a lifetime that's shorter than the service's lifetime.

수명 및 등록 옵션Lifetime and registration options

서비스 수명 및 등록 옵션 간의 차이점을 살펴보려면 작업을 식별자인 OperationId가 부여된 작업으로 나타내는 다음 인터페이스를 고려해 보세요.To demonstrate the difference between service lifetimes and their registration options, consider the following interfaces that represent a task as an operation with an identifier, OperationId. 다음 인터페이스들에 대해 작업 서비스의 수명을 구성하는 방법에 따라 컨테이너는 클래스에서 요청할 때 서비스의 같은 인스턴스나 다른 인스턴스를 제공합니다.Depending on how the lifetime of an operation's service is configured for the following interfaces, the container provides either the same or different instances of the service when requested by a class:

public interface IOperation
{
    string OperationId { get; }
}

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

다음 Operation 클래스는 위의 모든 인터페이스를 구현합니다.The following Operation class implements all of the preceding interfaces. Operation 생성자는 GUID를 생성하고 마지막 4자를 OperationId 속성에 저장합니다.The Operation constructor generates a GUID and stores the last 4 characters in the OperationId property:

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

    public string OperationId { get; }
}

Startup.ConfigureServices 메서드는 명명된 수명에 따라 Operation 클래스의 여러 등록을 만듭니다.The Startup.ConfigureServices method creates multiple registrations of the Operation class according to the named lifetimes:

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

    services.AddRazorPages();
}

샘플 앱에서는 요청 내의 개체 수명과 요청 간의 개체 수명을 모두 보여 줍니다.The sample app demonstrates object lifetimes both within and between requests. IndexModel 및 미들웨어는 각 IOperation 형식을 요청하고 각각에 대한 OperationId를 기록합니다.The IndexModel and the middleware request each kind of IOperation type and log the OperationId for each:

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과 유사한 미들웨어는 동일한 서비스를 해결합니다.Similar to the IndexModel, the middleware resolves the same services:

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 메서드에서 해결해야 합니다.Scoped services must be resolved in the InvokeAsync method:

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);
}

로거 출력은 다음을 보여 줍니다.The logger output shows:

  • Transient 개체는 항상 다릅니다.Transient objects are always different. 임시 OperationId 값은 IndexModel과 미들웨어에서 다릅니다.The transient OperationId value is different in the IndexModel and in the middleware.
  • ‘범위가 지정된’ 개체는 각 요청에 대해 동일하지만 각 요청 간에 다릅니다.Scoped objects are the same for each request but different across each request.
  • ‘싱글톤’ 개체는 모든 요청에 동일합니다.Singleton objects are the same for every request.

로깅 출력을 줄이려면 appsettings.Development.json 파일에서 “Logging:LogLevel:Microsoft:Error”를 설정합니다.To reduce the logging output, set "Logging:LogLevel:Microsoft:Error" in the appsettings.Development.json file:

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

Main에서 서비스 호출Call services from main

IServiceScopeFactory.CreateScope를 사용하여 IServiceScope를 만들어서 앱 범위 내로 범위가 지정된 서비스를 해결합니다.Create an IServiceScope with IServiceScopeFactory.CreateScope to resolve a scoped service within the app's scope. 이 방법은 시작 시 범위가 지정된 서비스에 액세스하여 초기화 작업을 실행하는 데 유용합니다.This approach is useful to access a scoped service at startup to run initialization tasks.

다음 예제에서는 범위가 지정된 IMyDependency 서비스에 액세스하고 Program.Main에서 해당 WriteMessage 메서드를 호출하는 방법을 보여 줍니다.The following example shows how to access the scoped IMyDependency service and call its WriteMessage method in Program.Main:

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>();
            });
}

범위 유효성 검사Scope validation

.NET의 종속성 주입생성자 주입 동작을 참조하세요.See Constructor injection behavior in Dependency injection in .NET

자세한 내용은 범위 유효성 검사를 참조하세요.For more information, see Scope validation.

요청 서비스Request Services

ASP.NET Core 요청 내에서 사용할 수 있는 서비스는 HttpContext.RequestServices 컬렉션을 통해 노출됩니다.The services available within an ASP.NET Core request are exposed through the HttpContext.RequestServices collection. 요청 내에서 서비스가 요청되는 경우 서비스와 해당 종속성은 RequestServices 컬렉션에서 확인됩니다.When services are requested from inside of a request, the services and their dependencies are resolved from the RequestServices collection.

프레임워크는 요청당 범위를 만들고 RequestServices는 범위가 지정된 서비스 공급자를 공개합니다.The framework creates a scope per request and RequestServices exposes the scoped service provider. 범위가 지정된 모든 서비스는 요청이 활성 상태인 동안 유효합니다.All scoped services are valid for as long as the request is active.

참고

RequestServices 컬렉션에 서비스를 확인하는 것보다 생성자 매개 변수로 종속성을 요청하는 것을 선호합니다.Prefer requesting dependencies as constructor parameters to resolving services from the RequestServices collection. 이 방법이 테스트하기 쉬운 클래스를 생성합니다.This results in classes that are easier to test.

종속성 주입을 위한 서비스 디자인Design services for dependency injection

종속성 주입을 위한 서비스를 디자인하는 경우When designing services for dependency injection:

  • 상태 저장 정적 클래스 및 멤버를 사용하지 마세요.Avoid stateful, static classes and members. 대신 싱글톤 서비스를 사용하도록 앱을 설계하여 전역 상태를 만들지 않도록 합니다.Avoid creating global state by designing apps to use singleton services instead.
  • 서비스 내의 종속 클래스를 직접 인스턴스화하지 마세요.Avoid direct instantiation of dependent classes within services. 직접 인스턴스화는 코드를 특정 구현에 결합합니다.Direct instantiation couples the code to a particular implementation.
  • 서비스를 작고 잘 구성되고 쉽게 테스트할 수 있도록 만듭니다.Make services small, well-factored, and easily tested.

클래스에 주입된 종속성이 많은 경우 클래스에 역할이 너무 많고 SRP(단일 책임 원칙)를 위반하는 것일 수 있습니다.If a class has a lot of injected dependencies, it might be a sign that the class has too many responsibilities and violates the Single Responsibility Principle (SRP). 해당 책임 몇 가지를 새로운 클래스로 이동하여 클래스를 리팩터링해 보세요.Attempt to refactor the class by moving some of its responsibilities into new classes. Razor Pages의 페이지 모델 클래스 및 MVC 컨트롤러 클래스는 UI 고려 사항에 집중해야 합니다.Keep in mind that Razor Pages page model classes and MVC controller classes should focus on UI concerns.

서비스 삭제Disposal of services

컨테이너는 자신이 만든 IDisposable 형식에 대해 Dispose를 호출합니다.The container calls Dispose for the IDisposable types it creates. 개발자는 컨테이너에서 확인된 서비스는 삭제해서는 안 됩니다.Services resolved from the container should never be disposed by the developer. 형식 또는 팩터리가 싱글톤으로 등록된 경우 컨테이너에서 싱글톤을 자동으로 삭제합니다.If a type or factory is registered as a singleton, the container disposes the singleton automatically.

다음 예제에서는 서비스가 서비스 컨테이너에 의해 만들어지고 자동으로 삭제됩니다.In the following example, the services are created by the service container and disposed automatically:

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");
    }
}

디버그 콘솔에는 인덱스 페이지를 새로 고칠 때마다 다음과 같은 출력이 표시됩니다.The debug console shows the following output after each refresh of the Index page:

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

서비스 컨테이너에서 만들지 않은 서비스Services not created by the service container

다음 코드를 살펴보세요.Consider the following code:

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

    services.AddRazorPages();
}

위의 코드에서In the preceding code:

  • 서비스 인스턴스가 서비스 컨테이너에 의해 만들어지지 않습니다.The service instances aren't created by the service container.
  • 프레임워크가 서비스를 자동으로 삭제하지 않습니다.The framework doesn't dispose of the services automatically.
  • 개발자가 서비스 삭제를 담당합니다.The developer is responsible for disposing the services.

임시 및 공유 인스턴스에 대한 IDisposable 지침IDisposable guidance for Transient and shared instances

.NET의 종속성 주입임시 및 공유 인스턴스에 대한 IDisposable 지침을 참조하세요.See IDisposable guidance for Transient and shared instance in Dependency injection in .NET

기본 서비스 컨테이너 바꾸기Default service container replacement

.NET의 종속성 주입기본 서비스 컨테이너 바꾸기를 참조하세요.See Default service container replacement in Dependency injection in .NET

권장 사항Recommendations

.NET의 종속성 주입권장 사항을 참조하세요.See Recommendations in Dependency injection in .NET

  • ‘서비스 로케이터 패턴’을 사용하지 마세요.Avoid using the service locator pattern. 예를 들어 DI를 대신 사용할 수 있는 경우 서비스 인스턴스를 가져오기 위해 GetService를 호출하지 마세요.For example, don't invoke GetService to obtain a service instance when you can use DI instead:

    잘못된 예:Incorrect:

    잘못된 코드

    올바른 예:Correct:

    public class MyClass
    {
        private readonly IOptionsMonitor<MyOptions> _optionsMonitor;
    
        public MyClass(IOptionsMonitor<MyOptions> optionsMonitor)
        {
            _optionsMonitor = optionsMonitor;
        }
    
        public void MyMethod()
        {
            var option = _optionsMonitor.CurrentValue.Option;
    
            ...
        }
    }
    
  • 피해야 하는 또 다른 서비스 로케이터 변형은 런타임에 종속성을 해결하는 팩터리를 주입하는 것입니다.Another service locator variation to avoid is injecting a factory that resolves dependencies at runtime. 이러한 두 가지 방법 모두 제어 반전 전략을 혼합합니다.Both of these practices mix Inversion of Control strategies.

  • HttpContext(예: IHttpContextAccessor.HttpContext)에 정적으로 액세스하지 마세요.Avoid static access to HttpContext (for example, IHttpContextAccessor.HttpContext).

  • ConfigureServices에서 BuildServiceProvider를 호출하지 마세요.Avoid calls to BuildServiceProvider in ConfigureServices. 일반적으로 BuildServiceProvider는 개발자가 ConfigureServices에서 서비스를 해결하려는 경우 호출합니다.Calling BuildServiceProvider typically happens when the developer wants to resolve a service in ConfigureServices. 구성에서 LoginPath를 로드하는 경우를 예로 들 수 있습니다.For example, consider the case where the LoginPath is loaded from configuration. 다음 방법을 사용하지 마세요.Avoid the following approach:

    BuildServiceProvider를 호출하는 잘못된 코드

    위 이미지에서 services.BuildServiceProvider 아래의 녹색 물결 모양 줄을 선택하면 다음 ASP0000 경고가 표시됩니다.In the preceding image, selecting the green wavy line under services.BuildServiceProvider shows the following ASP0000 warning:

    ASP0000 애플리케이션 코드에서 ‘BuildServiceProvider’를 호출하면 싱글톤 서비스의 추가 복사본이 생성됩니다.ASP0000 Calling 'BuildServiceProvider' from application code results in an additional copy of singleton services being created. ‘Configure’의 매개 변수로 종속성 주입 서비스와 같은 다른 방법을 고려하세요.Consider alternatives such as dependency injecting services as parameters to 'Configure'.

    BuildServiceProvider를 호출하면 두 번째 컨테이너가 만들어지므로, 조각난 싱글톤이 생성되고 여러 컨테이너의 개체 그래프를 참조할 수 있습니다.Calling BuildServiceProvider creates a second container, which can create torn singletons and cause references to object graphs across multiple containers.

    LoginPath를 가져오는 올바른 방법은 DI에 대한 옵션 패턴의 기본 제공 지원을 사용하는 것입니다.A correct way to get LoginPath is to use the options pattern's built-in support for 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();
    }
    
  • 삭제 가능한 임시 서비스는 삭제를 위해 컨테이너에서 캡처됩니다.Disposable transient services are captured by the container for disposal. 따라서 최상위 컨테이너에서 해결할 경우 메모리 누수가 발생할 수 있습니다.This can turn into a memory leak if resolved from the top level container.

  • 범위 유효성 검사를 사용하여 범위가 지정된 서비스를 캡처하는 싱글톤이 앱에 없는지 확인합니다.Enable scope validation to make sure the app doesn't have singletons that capture scoped services. 자세한 내용은 범위 유효성 검사를 참조하세요.For more information, see Scope validation.

모든 권장 사항과 마찬가지로, 권장 사항을 무시해야 하는 상황이 발생할 수 있습니다.Like all sets of recommendations, you may encounter situations where ignoring a recommendation is required. 예외는 드물게 발생하며 대부분 프레임워크 자체 내에서 특별한 경우에만 발생합니다.Exceptions are rare, mostly special cases within the framework itself.

DI는 정적/전역 개체 액세스 패턴의 ‘대안’입니다.DI is an alternative to static/global object access patterns. 고정 개체 액세스와 함께 사용할 경우 DI의 장점을 실현할 수 없습니다.You may not be able to realize the benefits of DI if you mix it with static object access.

Orchard Core는 ASP.NET Core에서 모듈식 다중 테넌트 애플리케이션을 빌드하기 위한 애플리케이션 프레임워크입니다.Orchard Core is an application framework for building modular, multi-tenant applications on ASP.NET Core. 자세한 내용은 Orchard Core 설명서를 참조하세요.For more information, see the Orchard Core Documentation.

CMS 고유 기능 없이 Orchard Core Framework를 사용하여 모듈식 다중 테넌트 앱을 빌드하는 방법에 대한 예제는 Orchard Core 샘플을 참조하세요.See the Orchard Core samples for examples of how to build modular and multi-tenant apps using just the Orchard Core Framework without any of its CMS-specific features.

프레임워크에서 제공하는 서비스Framework-provided services

Startup.ConfigureServices 메서드는 Entity Framework Core 및 ASP.NET Core MVC와 같은 플랫폼 기능을 비롯해 앱이 사용하는 서비스를 등록합니다.The Startup.ConfigureServices method registers services that the app uses, including platform features, such as Entity Framework Core and ASP.NET Core MVC. 처음에 ConfigureServices에 제공되는 IServiceCollection에는 호스트가 구성된 방법에 따라 달라지는 프레임워크에 의해 정의되는 서비스가 있습니다.Initially, the IServiceCollection provided to ConfigureServices has services defined by the framework depending on how the host was configured. ASP.NET Core 템플릿을 기반으로 하는 앱의 경우 프레임워크에서 250개 이상의 서비스를 등록합니다.For apps based on the ASP.NET Core templates, the framework registers more than 250 services.

다음 표에는 프레임워크에서 등록한 서비스들의 작은 샘플이 나열되어 있습니다.The following table lists a small sample of these framework-registered services:

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

추가 자료Additional resources

작성자: Steve Smith, Scott AddieBrandon DahlerBy Steve Smith, Scott Addie, and Brandon Dahler

ASP.NET Core는 클래스와 해당 종속성 간의 IoC(Inversion of Control)를 실현하는 기술인 DI(종속성 주입) 소프트웨어 디자인 패턴을 지원합니다.ASP.NET Core supports the dependency injection (DI) software design pattern, which is a technique for achieving Inversion of Control (IoC) between classes and their dependencies.

MVC 컨트롤러 내의 종속성 주입에 대한 자세한 내용은 ASP.NET Core의 컨트롤러에 종속성 주입을 참조하세요.For more information specific to dependency injection within MVC controllers, see ASP.NET Core의 컨트롤러에 종속성 주입.

예제 코드 살펴보기 및 다운로드 (다운로드 방법)View or download sample code (how to download)

종속성 주입 개요Overview of dependency injection

‘종속성’은 다른 개체에 필요한 모든 개체입니다.A dependency is any object that another object requires. 앱의 다른 클래스가 종속된 MyDependency 클래스에서 WriteMessage 메서드를 사용하는 다음 코드를 살펴보세요.Examine the following MyDependency class with a WriteMessage method that other classes in an app depend upon:

public class MyDependency
{
    public MyDependency()
    {
    }

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

        return Task.FromResult(0);
    }
}

MyDependency 클래스의 인스턴스를 만들어 클래스에서 WriteMessage 메서드를 사용할 수 있게 할 수 있습니다.An instance of the MyDependency class can be created to make the WriteMessage method available to a class. MyDependency 클래스는 IndexModel 클래스의 종속성입니다.The MyDependency class is a dependency of the IndexModel class:

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

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

이 클래스는 MyDependency 인스턴스를 만들고 이 인스턴스에 직접 종속됩니다.The class creates and directly depends on the MyDependency instance. 이전 예제와 같은 코드 종속성은 문제가 있으며 다음과 같은 이유로 사용하지 않아야 합니다.Code dependencies (such as the previous example) are problematic and should be avoided for the following reasons:

  • MyDependency를 다른 구현으로 바꾸려면 클래스를 수정해야 합니다.To replace MyDependency with a different implementation, the class must be modified.
  • MyDependency에 종속성이 있으면 클래스에서 해당 종속성을 구성해야 합니다.If MyDependency has dependencies, they must be configured by the class. 여러 클래스가 MyDependency에 종속되어 있는 대형 프로젝트에서는 구성 코드가 앱 전체에 분산됩니다.In a large project with multiple classes depending on MyDependency, the configuration code becomes scattered across the app.
  • 이 구현은 단위 테스트하기가 어렵습니다.This implementation is difficult to unit test. 앱에서 모의 또는 스텁 MyDependency 클래스를 사용해야 하지만, 이 방법에서는 가능하지 않습니다.The app should use a mock or stub MyDependency class, which isn't possible with this approach.

종속성 주입은 다음을 통해 이러한 문제를 해결합니다.Dependency injection addresses these problems through:

  • 인퍼테이스 또는 기본 클래스를 사용하여 종속성 구현을 추상화합니다.The use of an interface or base class to abstract the dependency implementation.
  • 서비스 컨테이너에 종속성 등록.Registration of the dependency in a service container. ASP.NET Core는 서비스 컨테이너인 IServiceProvider를 기본 제공합니다.ASP.NET Core provides a built-in service container, IServiceProvider. 서비스는 앱의 Startup.ConfigureServices 메서드에서 등록됩니다.Services are registered in the app's Startup.ConfigureServices method.
  • 서비스가 사용되는 클래스의 생성자에 주입됨.Injection of the service into the constructor of the class where it's used. 프레임워크가 종속성의 인스턴스를 만들고 더 이상 필요하지 않으면 삭제하는 작업을 담당합니다.The framework takes on the responsibility of creating an instance of the dependency and disposing of it when it's no longer needed.

샘플 앱에서 IMyDependency 인터페이스는 서비스가 앱에 제공하는 메서드를 정의합니다.In the sample app, the IMyDependency interface defines a method that the service provides to the app:

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

이 인터페이스는 구체적인 형식 MyDependency에서 구현됩니다.This interface is implemented by a concrete type, 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>를 요청합니다.MyDependency requests an ILogger<TCategoryName> in its constructor. 종속성 주입을 연결된 방식으로 사용하는 일은 특별한 경우가 아닙니다.It's not unusual to use dependency injection in a chained fashion. 요청된 각 종속성은 차례로 자체 종속성을 요청합니다.Each requested dependency in turn requests its own dependencies. 컨테이너는 그래프의 종속성을 해결하고 완전히 해결된 서비스를 반환합니다.The container resolves the dependencies in the graph and returns the fully resolved service. 해결해야 하는 종속성이 모인 집합은 일반적으로 종속성 트리, 종속성 그래프 또는 개체 그래프라고 합니다 .The collective set of dependencies that must be resolved is typically referred to as a dependency tree, dependency graph, or object graph.

IMyDependencyILogger<TCategoryName>는 서비스 컨테이너에 등록되어야 합니다.IMyDependency and ILogger<TCategoryName> must be registered in the service container. IMyDependencyStartup.ConfigureServices에서 등록됩니다.IMyDependency is registered in Startup.ConfigureServices. ILogger<TCategoryName>은 로깅 추상화 인프라에서 등록하므로, 프레임워크에서 기본적으로 등록한 프레임워크 제공 서비스입니다.ILogger<TCategoryName> is registered by the logging abstractions infrastructure, so it's a framework-provided service registered by default by the framework.

컨테이너는 개방형 형식(제네릭)을 활용하여 ILogger<TCategoryName>을 해결하므로 모든 생성된 형식(제네릭)을 등록하지 않아도 됩니다.The container resolves ILogger<TCategoryName> by taking advantage of (generic) open types, eliminating the need to register every (generic) constructed type:

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

샘플 앱에서 IMyDependency 서비스는 구체적인 형식 MyDependency로 등록됩니다.In the sample app, the IMyDependency service is registered with the concrete type MyDependency. 이 등록은 서비스 수명을 단일 요청의 수명으로 지정합니다.The registration scopes the service lifetime to the lifetime of a single request. 서비스 수명에 대해서는 이 항목의 뒷부분에서 설명합니다.Service lifetimes are described later in this topic.

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} 확장 메서드는 서비스를 추가하고 잠재적으로 구성합니다.Each services.Add{SERVICE_NAME} extension method adds, and potentially configures, services. 예를 들어 services.AddControllersWithViews, services.AddRazorPages, services.AddControllers는 앱에 필요한 서비스 ASP.NET Core 앱을 추가합니다.For example, services.AddControllersWithViews, services.AddRazorPages, and services.AddControllers adds the services ASP.NET Core apps require. 앱에서 이 규칙을 따르는 것이 좋습니다.We recommended that apps follow this convention. 확장 메서드를 Microsoft.Extensions.DependencyInjection 네임스페이스에 배치하여 서비스 등록 그룹을 캡슐화합니다.Place extension methods in the Microsoft.Extensions.DependencyInjection namespace to encapsulate groups of service registrations. DI 확장 메서드에 대해 Microsoft.Extensions.DependencyInjection 네임스페이스 부분을 포함하면 다음도 가능합니다.Including the namespace portion Microsoft.Extensions.DependencyInjection for DI extension methods also:

  • 더 이상의 using 블록을 추가하지 않고도 IntelliSense에 표시할 수 있습니다.Allows them to be displayed in IntelliSense without adding additional using blocks.
  • 이러한 확장 메서드가 일반적으로 호출되는 Startup 클래스의 과도한 using 문을 방지합니다.Prevents excessive using statements in the Startup class where these extension methods are typically called from.

서비스의 생성자에 string과 같은 기본 제공 형식이 필요한 경우 구성옵션 패턴을 사용하여 해당 형식을 삽입할 수 있습니다.If the service's constructor requires a built in type, such as a string, the type can be injected by using configuration or the options pattern:

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

        // Use myStringValue
    }

    ...
}

서비스의 인스턴스는 서비스가 사용되는 클래스의 생성자를 통해 요청되고 전용 필드에 할당됩니다.An instance of the service is requested via the constructor of a class where the service is used and assigned to a private field. 이 필드는 클래스 전체에서 필요에 따라 서비스에 액세스하는 데 사용됩니다.The field is used to access the service as necessary throughout the class.

샘플 앱에서는 IMyDependency 인스턴스가 요청되며 이 인스턴스는 서비스의 WriteMessage 메서드를 호출하는 데 사용됩니다.In the sample app, the IMyDependency instance is requested and used to call the service's WriteMessage method:

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.");
    }
}

시작에 삽입된 서비스Services injected into Startup

제네릭 호스트(IHostBuilder)를 사용할 경우 다음 서비스 유형만 Startup 생성자에 삽입할 수 있습니다.Only the following service types can be injected into the Startup constructor when using the Generic Host (IHostBuilder):

서비스는 Startup.Configure에 삽입할 수 있습니다.Services can be injected into Startup.Configure:

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

자세한 내용은 ASP.NET Core에서 앱 시작를 참조하세요.For more information, see ASP.NET Core에서 앱 시작.

프레임워크에서 제공하는 서비스Framework-provided services

Startup.ConfigureServices 메서드는 Entity Framework Core 및 ASP.NET Core MVC와 같은 플랫폼 기능을 비롯해 앱이 사용하는 서비스를 정의합니다.The Startup.ConfigureServices method is responsible for defining the services that the app uses, including platform features, such as Entity Framework Core and ASP.NET Core MVC. 처음에 ConfigureServices에 제공되는 IServiceCollection에는 호스트가 구성된 방법에 따라 달라지는 프레임워크에 의해 정의되는 서비스가 있습니다.Initially, the IServiceCollection provided to ConfigureServices has services defined by the framework depending on how the host was configured. ASP.NET Core 템플릿을 기반으로 하는 앱의 경우 프레임워크에 의해 등록된 수백 개의 서비스를 가지는 것은 드문 일이 아닙니다.It's not uncommon for an app based on an ASP.NET Core template to have hundreds of services registered by the framework. 다음 표에는 프레임워크에서 등록한 서비스들의 작은 샘플이 나열되어 있습니다.A small sample of framework-registered services is listed in the following table.

서비스 종류Service Type 수명Lifetime
Microsoft.AspNetCore.Hosting.Builder.IApplicationBuilderFactory TransientTransient
Microsoft.AspNetCore.Hosting.IApplicationLifetime SingletonSingleton
Microsoft.AspNetCore.Hosting.IHostingEnvironment SingletonSingleton
Microsoft.AspNetCore.Hosting.IStartup SingletonSingleton
Microsoft.AspNetCore.Hosting.IStartupFilter TransientTransient
Microsoft.AspNetCore.Hosting.Server.IServer SingletonSingleton
Microsoft.AspNetCore.Http.IHttpContextFactory TransientTransient
Microsoft.Extensions.Logging.ILogger<TCategoryName> SingletonSingleton
Microsoft.Extensions.Logging.ILoggerFactory SingletonSingleton
Microsoft.Extensions.ObjectPool.ObjectPoolProvider SingletonSingleton
Microsoft.Extensions.Options.IConfigureOptions<TOptions> TransientTransient
Microsoft.Extensions.Options.IOptions<TOptions> SingletonSingleton
System.Diagnostics.DiagnosticSource SingletonSingleton
System.Diagnostics.DiagnosticListener SingletonSingleton

확장 메서드를 사용하여 추가 서비스 등록Register additional services with extension methods

서비스 컬렉션 확장 메서드를 사용하여 서비스(및 필요한 경우 해당 종속 서비스)를 등록할 수 있는 경우 단일 Add{SERVICE_NAME} 확장 메서드를 사용하여 해당 서비스에 필요한 모든 서비스를 등록하는 것이 규칙입니다.When a service collection extension method is available to register a service (and its dependent services, if required), the convention is to use a single Add{SERVICE_NAME} extension method to register all of the services required by that service. 다음 코드는 확장 메서드 AddDbContext<TContext>AddIdentityCore를 사용하여 컨테이너에 서비스를 추가하는 방법을 보여 주는 예제입니다.The following code is an example of how to add additional services to the container using the extension methods AddDbContext<TContext> and AddIdentityCore:

public void ConfigureServices(IServiceCollection services)
{
    ...

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

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

    ...
}

자세한 내용은 API 설명서의 ServiceCollection 클래스를 참조하세요.For more information, see the ServiceCollection class in the API documentation.

서비스 수명Service lifetimes

등록된 각 서비스의 수명을 적절히 선택합니다.Choose an appropriate lifetime for each registered service. ASP.NET Core 서비스는 다음 수명을 사용하여 구성할 수 있습니다.ASP.NET Core services can be configured with the following lifetimes:

TransientTransient

Transient 수명 서비스(AddTransient)는 서비스 컨테이너에서 요청할 때마다 만들어집니다.Transient lifetime services (AddTransient) are created each time they're requested from the service container. 이 수명은 간단한 상태 비저장 서비스에 가장 적합합니다.This lifetime works best for lightweight, stateless services.

요청을 처리하는 앱에서 Transient 서비스는 요청이 끝날 때 삭제됩니다.In apps that process requests, transient services are disposed at the end of the request.

ScopedScoped

Scoped 수명 서비스(AddScoped)는 클라이언트 요청(연결)당 한 번 생성됩니다.Scoped lifetime services (AddScoped) are created once per client request (connection).

요청을 처리하는 앱에서 Scoped 서비스는 요청이 끝날 때 삭제됩니다.In apps that process requests, scoped services are disposed at the end of the request.

경고

미들웨어에서 범위가 지정된 서비스를 사용하는 경우 Invoke 또는 InvokeAsync 메서드에 서비스를 삽입합니다.When using a scoped service in a middleware, inject the service into the Invoke or InvokeAsync method. 생성자 삽입은 서비스가 singleton처럼 작동하게 하므로 이러한 방법으로 삽입하지 마세요.Don't inject via constructor injection because it forces the service to behave like a singleton. 자세한 내용은 사용자 지정 ASP.NET Core 미들웨어 작성를 참조하세요.For more information, see 사용자 지정 ASP.NET Core 미들웨어 작성.

SingletonSingleton

싱글톤 수명 서비스(AddSingleton)는 처음 요청할 때(또는 Startup.ConfigureServices를 실행하고 서비스 등록에서 인스턴스를 지정하는 경우) 생성됩니다.Singleton lifetime services (AddSingleton) are created the first time they're requested (or when Startup.ConfigureServices is run and an instance is specified with the service registration). 모든 후속 요청에서는 같은 인스턴스를 사용합니다.Every subsequent request uses the same instance. 앱에 싱글톤 동작이 필요한 경우 서비스 컨테이너가 서비스 수명을 관리하도록 허용하는 것이 좋습니다.If the app requires singleton behavior, allowing the service container to manage the service's lifetime is recommended. 싱글톤 디자인 패턴을 구현하거나 클래스의 개체 수명을 관리하는 사용자 코드를 제공하지 마세요.Don't implement the singleton design pattern and provide user code to manage the object's lifetime in the class.

요청을 처리하는 앱에서 Singleton 서비스는 앱 종료 시 ServiceProvider가 삭제될 때 삭제됩니다.In apps that process requests, singleton services are disposed when the ServiceProvider is disposed at app shutdown.

경고

범위가 지정된 서비스를 싱글톤에서 해결하면 위험합니다.It's dangerous to resolve a scoped service from a singleton. 이 경우 후속 요청을 처리할 때 서비스가 잘못된 상태일 수 있습니다.It may cause the service to have incorrect state when processing subsequent requests.

서비스 등록 메서드Service registration methods

서비스 등록 확장 메서드는 특정 시나리오에 유용한 오버로드를 제공합니다.Service registration extension methods offer overloads that are useful in specific scenarios.

메서드Method 자동Automatic
개체object
삭제disposal
여러Multiple
구현implementations
인수 전달Pass args
Add{LIFETIME}<{SERVICE}, {IMPLEMENTATION}>()
예제:Example:
services.AddSingleton<IMyDep, MyDep>();
Yes Yes 아니요No
Add{LIFETIME}<{SERVICE}>(sp => new {IMPLEMENTATION})
예제:Examples:
services.AddSingleton<IMyDep>(sp => new MyDep());
services.AddSingleton<IMyDep>(sp => new MyDep("A string!"));
Yes Yes Yes
Add{LIFETIME}<{IMPLEMENTATION}>()
예제:Example:
services.AddSingleton<MyDep>();
Yes 아니요No 아니요No
AddSingleton<{SERVICE}>(new {IMPLEMENTATION})
예제:Examples:
services.AddSingleton<IMyDep>(new MyDep());
services.AddSingleton<IMyDep>(new MyDep("A string!"));
아니요No Yes Yes
AddSingleton(new {IMPLEMENTATION})
예제:Examples:
services.AddSingleton(new MyDep());
services.AddSingleton(new MyDep("A string!"));
아니요No 아니요No Yes

형식 삭제에 대한 자세한 내용은 서비스의 삭제 섹션을 참조하세요.For more information on type disposal, see the Disposal of services section. 여러 구현에 대한 일반적인 시나리오는 테스트용 모의 형식입니다.A common scenario for multiple implementations is mocking types for testing.

구현 형식만으로 서비스를 등록하는 것은 동일한 구현 및 서비스 형식으로 해당 서비스를 등록하는 것과 같습니다.Registering a service with only an implementation type is equivalent to registering that service with the same implementation and service type. 따라서 명시적 서비스 형식을 사용하지 않는 메서드를 사용하여 서비스의 여러 구현을 등록할 수 없습니다.This is why multiple implementations of a service cannot be registered using the methods that don't take an explicit service type. 이러한 메서드는 서비스의 여러 ‘인스턴스’를 등록할 수 있지만 모두 동일한 ‘구현’ 형식을 사용합니다. These methods can register multiple instances of a service, but they will all have the same implementation type.

위의 서비스 등록 메서드 중 하나를 사용하여 동일한 서비스 형식의 여러 서비스 인스턴스를 등록할 수 있습니다.Any of the above service registration methods can be used to register multiple service instances of the same service type. 다음 예제에서는 IMyDependency를 서비스 형식으로 사용하여 AddSingleton을 두 번 호출합니다.In the following example, AddSingleton is called twice with IMyDependency as the service type. 두 번째 AddSingleton 호출은 IMyDependency로 확인되면 이전 호출을 재정의하고 IEnumerable<IMyDependency>를 통해 여러 서비스가 확인되면 이전 호출에 추가됩니다.The second call to AddSingleton overrides the previous one when resolved as IMyDependency and adds to the previous one when multiple services are resolved via IEnumerable<IMyDependency>. 서비스는 IEnumerable<{SERVICE}>를 통해 해결될 때 등록된 순서로 나타납니다.Services appear in the order they were registered when resolved via 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} 확장 메서드를 제공합니다.The framework also provides TryAdd{LIFETIME} extension methods, which register the service only if there isn't already an implementation registered.

다음 예제에서 AddSingleton을 호출하면 MyDependencyIMyDependency에 대한 구현으로 등록됩니다.In the following example, the call to AddSingleton registers MyDependency as an implementation for IMyDependency. TryAddSingleton 호출은 IMyDependency에 이미 등록된 구현이 있기 때문에 아무런 효과가 없습니다.The call to TryAddSingleton has no effect because IMyDependency already has a registered implementation.

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);
    }
}

자세한 내용은 다음을 참조하세요.For more information, see:

TryAddEnumerable(ServiceDescriptor) 메서드는 동일한 형식 의 구현이 아직 없는 경우에만 서비스를 등록합니다.TryAddEnumerable(ServiceDescriptor) methods only register the service if there isn't already an implementation of the same type. 여러 서비스가 IEnumerable<{SERVICE}>를 통해 해결됩니다.Multiple services are resolved via IEnumerable<{SERVICE}>. 서비스를 등록할 때 개발자는 동일한 유형 중 하나가 아직 추가되지 않은 경우에만 인스턴스를 추가하려고 합니다.When registering services, the developer only wants to add an instance if one of the same type hasn't already been added. 일반적으로 이 메서드는 라이브러리 작성자가 컨테이너에 두 개 복사본을 등록하지 않도록 하기 위해 사용됩니다.Generally, this method is used by library authors to avoid registering two copies of an instance in the container.

다음 예제에서 첫 번째 줄은 IMyDep1에 대한 MyDep를 등록합니다.In the following example, the first line registers MyDep for IMyDep1. 두 번째 줄은 IMyDep2에 대한 MyDep를 등록합니다.The second line registers MyDep for IMyDep2. 세 번째 줄은 IMyDep1에 이미 MyDep의 등록된 구현이 이미 있으므로 아무런 효과가 없습니다.The third line has no effect because IMyDep1 already has a registered implementation of 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>());

생성자 주입 동작Constructor injection behavior

다음 두 가지 메커니즘으로 서비스를 해결할 수 있습니다.Services can be resolved by two mechanisms:

  • IServiceProvider
  • ActivatorUtilities: 종속성 주입 컨테이너에 서비스 등록 없이 개체를 생성할 수 있습니다.ActivatorUtilities: Permits object creation without service registration in the dependency injection container. ActivatorUtilities는 태그 도우미, MVC 컨트롤러 및 모델 바인더와 같은 사용자용 추상화에 사용됩니다.ActivatorUtilities is used with user-facing abstractions, such as Tag Helpers, MVC controllers, and model binders.

생성자에는 종속성 주입으로 제공되지 않는 인수를 사용할 수 있지만, 인수에 기본값을 할당해야 합니다.Constructors can accept arguments that aren't provided by dependency injection, but the arguments must assign default values.

IServiceProvider 또는 ActivatorUtilities로 서비스를 해결하는 경우 생성자 주입public 생성자가 필요합니다.When services are resolved by IServiceProvider or ActivatorUtilities, constructor injection requires a public constructor.

ActivatorUtilities로 서비스를 해결하는 경우 생성자 주입을 위해서는 적합한 생성자가 하나만 있어야 합니다.When services are resolved by ActivatorUtilities, constructor injection requires that only one applicable constructor exists. 생성자 오버로드가 지원되지만, 해당 인수가 모두 종속성 주입으로 처리될 수 있는 하나의 오버로드만 존재할 수 있습니다.Constructor overloads are supported, but only one overload can exist whose arguments can all be fulfilled by dependency injection.

Entity Framework 컨텍스트Entity Framework contexts

Entity Framework 컨텍스트는 일반적으로 범위가 지정된 수명을 사용하여 서비스 컨테이너에 추가됩니다. 이는 웹앱 데이터베이스 작업이 일반적으로 클라이언트 요청에 따라 범위가 지정되기 때문입니다.Entity Framework contexts are usually added to the service container using the scoped lifetime because web app database operations are normally scoped to the client request. 데이터베이스 컨텍스트를 등록할 때 AddDbContext<TContext> 오버로드로 수명을 지정하지 않으면 기본 수명으로 수명 범위가 지정됩니다.The default lifetime is scoped if a lifetime isn't specified by an AddDbContext<TContext> overload when registering the database context. 지정된 수명의 서비스는 서비스보다 수명이 짧은 데이터베이스 컨텍스트를 사용해서는 안됩니다.Services of a given lifetime shouldn't use a database context with a shorter lifetime than the service.

수명 및 등록 옵션Lifetime and registration options

이러한 수명 및 등록 옵션 간의 차이점을 살펴보려면 작업을 고유한 ID인 OperationId가 부여된 작업으로 나타내는 다음 인터페이스들을 고려해 보세요.To demonstrate the difference between the lifetime and registration options, consider the following interfaces that represent tasks as an operation with a unique identifier, OperationId. 다음 인터페이스들에 대해 작업 서비스의 수명을 구성하는 방법에 따라 컨테이너는 클래스에서 요청할 때 서비스의 같은 인스턴스나 다른 인스턴스를 제공합니다.Depending on how the lifetime of an operations service is configured for the following interfaces, the container provides either the same or a different instance of the service when requested by a class:

public interface IOperation
{
    Guid OperationId { get; }
}

public interface IOperationTransient : IOperation
{
}

public interface IOperationScoped : IOperation
{
}

public interface IOperationSingleton : IOperation
{
}

public interface IOperationSingletonInstance : IOperation
{
}

인터페이스들은 Operation 클래스에서 구현됩니다.The interfaces are implemented in the Operation class. Operation 생성자는 GUID가 제공되지 않는 경우 GUID를 생성합니다.The Operation constructor generates a GUID if one isn't supplied:

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 형식에 종속되어 등록됩니다.An OperationService is registered that depends on each of the other Operation types. 종속성 주입을 통해 OperationService를 요청하면 종속 서비스의 수명에 따라 각 서비스의 새 인스턴스나 기존 인스턴스를 받습니다.When OperationService is requested via dependency injection, it receives either a new instance of each service or an existing instance based on the lifetime of the dependent service.

  • 컨테이너에서 요청할 때 임시 서비스가 생성되면 IOperationTransient 서비스의 OperationIdOperationServiceOperationId와 다릅니다.When transient services are created when requested from the container, the OperationId of the IOperationTransient service is different than the OperationId of the OperationService. OperationServiceIOperationTransient 클래스의 새 인스턴스를 받습니다.OperationService receives a new instance of the IOperationTransient class. 새 인스턴스는 다른 OperationId를 생성합니다.The new instance yields a different OperationId.
  • 클라이언트 요청에 따라 범위가 지정된 서비스가 생성되면 IOperationScoped 서비스의 OperationId는 클라이언트 요청 내의 OperationService와 같습니다.When scoped services are created per client request, the OperationId of the IOperationScoped service is the same as that of OperationService within a client request. 전체 클라이언트 요청에서 두 서비스는 다른 OperationId 값을 공유합니다.Across client requests, both services share a different OperationId value.
  • 싱글톤 및 싱글톤 인스턴스 서비스가 한 번 생성되어 모든 클라이언트 요청 및 모든 서비스에서 사용될 경우 OperationId는 모든 서비스 요청에서 동일합니다.When singleton and singleton-instance services are created once and used across all client requests and all services, the OperationId is constant across all service requests.
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에서 각 형식이 자신의 명명된 수명에 따라 컨테이너에 추가됩니다.In Startup.ConfigureServices, each type is added to the container according to its named lifetime:

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인 특정 인스턴스를 사용 중입니다.The IOperationSingletonInstance service is using a specific instance with a known ID of Guid.Empty. 이 형식이 사용 중임을 명확하게 알 수 있습니다(이 인스턴스의 GUID는 모두 0입니다).It's clear when this type is in use (its GUID is all zeroes).

이 샘플 앱은 개별 요청 내의 개체 수명과 개별 요청 간의 개체 수명을 보여 줍니다.The sample app demonstrates object lifetimes within and between individual requests. 샘플 앱의 IndexModel은 각 종류의 IOperation 형식과 OperationService를 요청합니다.The sample app's IndexModel requests each kind of IOperation type and the OperationService. 그런 다음, 페이지에서는 속성 할당을 통해 페이지 모델 클래스 및 서비스의 OperationId 값을 모두 표시합니다.The page then displays all of the page model class's and service's OperationId values through property assignments:

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.");
    }
}

다음 출력은 두 요청의 결과를 보여 줍니다.Two following output shows the results of two requests:

첫 번째 요청: :First request:

컨트롤러 작업:Controller operations:

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

OperationService 작업:OperationService operations:

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

두 번째 요청:Second request:

컨트롤러 작업:Controller operations:

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

OperationService 작업:OperationService operations:

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

어떤 OperationId 값이 요청 내에서 그리고 요청 간에 달라지는지 확인합니다.Observe which of the OperationId values vary within a request and between requests:

  • Transient 개체는 항상 다릅니다.Transient objects are always different. 첫 번째와 두 번째 클라이언트 요청에 대한 임시 OperationId 값은 OperationService 작업과 클라이언트 요청 간에 모두 다릅니다.The transient OperationId value for both the first and second client requests are different for both OperationService operations and across client requests. 각 서비스 요청과 클라이언트 요청에 새 인스턴스가 제공됩니다.A new instance is provided to each service request and client request.
  • Scoped 개체는 클라이언트 요청 내에서는 동일하지만 클라이언트 요청 간에는 다릅니다.Scoped objects are the same within a client request but different across client requests.
  • Singleton 개체는 Startup.ConfigureServices에서 Operation 인스턴스 제공 여부와 관계없이 모든 개체 및 모든 요청에 대해 동일합니다.Singleton objects are the same for every object and every request regardless of whether an Operation instance is provided in Startup.ConfigureServices.

Main에서 서비스 호출Call services from main

IServiceScopeFactory.CreateScope를 사용하여 IServiceScope를 만들어서 앱 범위 내로 범위가 지정된 서비스를 해결합니다.Create an IServiceScope with IServiceScopeFactory.CreateScope to resolve a scoped service within the app's scope. 이 방법은 시작 시 범위가 지정된 서비스에 액세스하여 초기화 작업을 실행하는 데 유용합니다.This approach is useful to access a scoped service at startup to run initialization tasks. 다음 예제에서는 Program.Main에서 MyScopedService에 대한 컨텍스트를 가져오는 방법을 보여 줍니다.The following example shows how to obtain a context for the MyScopedService in Program.Main:

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>();
}

범위 유효성 검사Scope validation

앱이 개발 환경에서 실행 중인 경우 기본 서비스 공급자가 다음을 확인하는 검사를 수행합니다.When the app is running in the Development environment, the default service provider performs checks to verify that:

  • '직접으로' in current translation is awkward/inappropriate in terms of grammar.Scoped services aren't directly or indirectly resolved from the root service provider.
  • 범위가 지정된 서비스는 직접 또는 간접적으로 싱글톤에 삽입되지 않습니다.Scoped services aren't directly or indirectly injected into singletons.

루트 서비스 공급자는 BuildServiceProvider를 호출할 때 만들어집니다.The root service provider is created when BuildServiceProvider is called. 루트 서비스 공급자의 수명은 공급자가 앱과 함께 시작되고 앱이 종료될 때 삭제되는 앱/서버의 수명에 해당합니다.The root service provider's lifetime corresponds to the app/server's lifetime when the provider starts with the app and is disposed when the app shuts down.

범위가 지정된 서비스는 서비스를 만든 컨테이너에 의해 삭제됩니다.Scoped services are disposed by the container that created them. 범위가 지정된 서비스가 루트 컨테이너에서 만들어지는 경우 서비스의 수명은 사실상 싱글톤으로 승격됩니다. 해당 서비스는 앱/서버가 종료될 때 루트 컨테이너에 의해서만 삭제되기 때문입니다.If a scoped service is created in the root container, the service's lifetime is effectively promoted to singleton because it's only disposed by the root container when app/server is shut down. 서비스 범위의 유효성 검사는 BuildServiceProvider가 호출될 경우 이러한 상황을 감지합니다.Validating service scopes catches these situations when BuildServiceProvider is called.

자세한 내용은 ASP.NET Core 웹 호스트를 참조하세요.For more information, see ASP.NET Core 웹 호스트.

요청 서비스Request Services

HttpContext의 ASP.NET Core 요청 내에서 사용할 수 있는 서비스는 HttpContext.RequestServices 컬렉션을 통해 노출됩니다.The services available within an ASP.NET Core request from HttpContext are exposed through the HttpContext.RequestServices collection.

요청 서비스는 앱의 일부로 구성 및 요청된 서비스를 나타냅니다.Request Services represent the services configured and requested as part of the app. 개체가 종속성을 지정한 경우에는 ApplicationServices가 아닌 RequestServices에 있는 형식으로 충족됩니다.When the objects specify dependencies, these are satisfied by the types found in RequestServices, not ApplicationServices.

일반적으로 앱은 이러한 속성을 직접 사용해서는 안 됩니다.Generally, the app shouldn't use these properties directly. 대신 클래스 생성자를 통해 클래스에 필요한 형식을 요청하고 프레임워크가 종속성을 주입하도록 합니다.Instead, request the types that classes require via class constructors and allow the framework inject the dependencies. 이 방법이 테스트하기 쉬운 클래스를 생성합니다.This yields classes that are easier to test.

참고

RequestServices 컬렉션에 액세스하는 것보다 생성자 매개 변수로 종속성을 요청하는 것을 선호합니다.Prefer requesting dependencies as constructor parameters to accessing the RequestServices collection.

종속성 주입을 위한 서비스 디자인Design services for dependency injection

모범 사례는 다음과 같습니다.Best practices are to:

  • 종속성 주입을 사용하여 종속성을 가져오도록 서비스를 디자인합니다.Design services to use dependency injection to obtain their dependencies.
  • 상태 저장 정적 클래스 및 멤버를 사용하지 마세요.Avoid stateful, static classes and members. 대신 singleton 서비스를 사용하여 전역 상태를 만들지 않도록 앱을 디자인합니다.Design apps to use singleton services instead, which avoid creating global state.
  • 서비스 내의 종속 클래스를 직접 인스턴스화하지 마세요.Avoid direct instantiation of dependent classes within services. 직접 인스턴스화는 코드를 특정 구현에 결합합니다.Direct instantiation couples the code to a particular implementation.
  • 앱 클래스를 작고 잘 구성되고 쉽게 테스트할 수 있도록 만듭니다.Make app classes small, well-factored, and easily tested.

클래스에 주입된 종속성이 너무 많아 보이면 일반적으로 클래스에 역할이 너무 많고 SRP(단일 책임 원칙)를 위반하는 것일 수 있습니다.If a class seems to have too many injected dependencies, this is generally a sign that the class has too many responsibilities and is violating the Single Responsibility Principle (SRP). 해당 책임 몇 가지를 새로운 클래스로 이동하여 클래스를 리팩터링해 보세요.Attempt to refactor the class by moving some of its responsibilities into a new class. Razor Pages의 페이지 모델 클래스 및 MVC 컨트롤러 클래스는 UI 고려 사항에 집중해야 합니다.Keep in mind that Razor Pages page model classes and MVC controller classes should focus on UI concerns. 비즈니스 규칙 및 데이터 액세스 구현 세부 정보는 이러한 문제의 분리에 적합한 클래스에 유지되어야 합니다.Business rules and data access implementation details should be kept in classes appropriate to these separate concerns.

서비스 삭제Disposal of services

컨테이너는 자신이 만든 IDisposable 형식에 대해 Dispose를 호출합니다.The container calls Dispose for the IDisposable types it creates. 인스턴스가 사용자 코드로 컨테이너에 추가된 경우에는 자동으로 삭제되지 않습니다.If an instance is added to the container by user code, it isn't disposed automatically.

다음 예제에서는 서비스가 서비스 컨테이너에 의해 만들어지고 자동으로 삭제됩니다.In the following example, the services are created by the service container and disposed automatically:

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());
}

다음 예제에서는In the following example:

  • 서비스 인스턴스가 서비스 컨테이너에 의해 만들어지지 않습니다.The service instances aren't created by the service container.
  • 의도된 서비스 수명을 프레임워크가 알지 못합니다.The intended service lifetimes aren't known by the framework.
  • 프레임워크가 서비스를 자동으로 삭제하지 않습니다.The framework doesn't dispose of the services automatically.
  • 개발자 코드에서 서비스가 명시적으로 삭제되지 않을 경우 해당 서비스는 앱이 종료될 때까지 유지됩니다.If the services aren't explicitly disposed in developer code, they persist until the app shuts down.
public class Service1 : IDisposable {}
public class Service2 : IDisposable {}

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

임시 및 공유 인스턴스에 대한 IDisposable 지침IDisposable guidance for Transient and shared instances

임시적인 제한 수명Transient, limited lifetime

시나리오Scenario

앱에는 다음 시나리오 중 하나에 대해 임시 수명으로 IDisposable 인스턴스가 필요합니다.The app requires an IDisposable instance with a transient lifetime for either of the following scenarios:

  • 인스턴스는 루트 범위에서 확인됩니다.The instance is resolved in the root scope.
  • 범위가 끝나기 전에 인스턴스를 삭제해야 합니다.The instance should be disposed before the scope ends.

해결 방법Solution

부모 범위 밖에서 인스턴스를 생성하려면 팩터리 패턴을 사용합니다.Use the factory pattern to create an instance outside of the parent scope. 이 경우 앱에는 일반적으로 최종 형식의 생성자를 직접 호출하는 Create 메서드가 있습니다.In this situation, the app would generally have a Create method that calls the final type's constructor directly. 최종 형식에 다른 종속성이 있는 경우 팩터리는 다음을 수행할 수 있습니다.If the final type has other dependencies, the factory can:

공유 인스턴스 및 제한 수명Shared Instance, limited lifetime

시나리오Scenario

앱은 여러 서비스에서 공유 IDisposable 인스턴스가 필요하지만 IDisposable는 수명이 제한되어 있어야 합니다.The app requires a shared IDisposable instance across multiple services, but the IDisposable should have a limited lifetime.

해결 방법Solution

인스턴스를 범위가 지정된 수명으로 등록합니다.Register the instance with a Scoped lifetime. IServiceScopeFactory.CreateScope를 사용하여 시작하고 새로운 IServiceScope를 생성합니다.Use IServiceScopeFactory.CreateScope to start and create a new IServiceScope. 범위의 IServiceProvider를 사용하여 필요한 서비스를 가져옵니다.Use the scope's IServiceProvider to get required services. 수명을 종료해야 하는 경우 범위를 삭제합니다.Dispose the scope when the lifetime should end.

일반 지침General Guidelines

  • 임시 범위에 IDisposable 인스턴스를 등록하지 마세요.Don't register IDisposable instances with a Transient scope. 대신 팩터리 패턴을 사용합니다.Use the factory pattern instead.
  • 루트 범위에서 임시 또는 범위가 지정된 IDisposable 인스턴스를 확인하지 마세요.Don't resolve Transient or Scoped IDisposable instances in the root scope. 일반적으로 유일한 예외는 앱이 이상적 패턴이 아닌 IServiceProvider를 생성/재생성 및 삭제하는 경우입니다.The only general exception is when the app creates/recreates and disposes the IServiceProvider, which isn't an ideal pattern.
  • DI를 통한 IDisposable 종속성 수신은 수신자가 자체적으로 IDisposable를 구현할 필요가 없습니다.Receiving an IDisposable dependency via DI doesn't require that the receiver implement IDisposable itself. IDisposable 종속성의 수신자는 해당 종속성에서 Dispose를 호출하지 않아야 합니다.The receiver of the IDisposable dependency shouldn't call Dispose on that dependency.
  • 범위는 서비스의 수명을 제어하는 데 사용되어야 합니다.Scopes should be used to control lifetimes of services. 범위는 계층적이지 않으며 범위 간 특수 연결이 없습니다.Scopes aren't hierarchical, and there's no special connection among scopes.

기본 서비스 컨테이너 바꾸기Default service container replacement

기본 제공 서비스 컨테이너는 프레임워크 및 대부분의 소비자 앱의 요구를 충족하기 위한 것입니다.The built-in service container is designed to serve the needs of the framework and most consumer apps. 기본 제공 컨테이너가 지원하지 않는 특정 기능이 필요하지 않는 한, 다음과 같은 기본 제공 컨테이너를 사용하는 것이 좋습니다.We recommend using the built-in container unless you need a specific feature that the built-in container doesn't support, such as:

  • 속성 삽입Property injection
  • 이름에 기반한 삽입Injection based on name
  • 자식 컨테이너Child containers
  • 사용자 지정 수명 관리Custom lifetime management
  • 초기화 지연에 대한 Func<T> 지원Func<T> support for lazy initialization
  • 규칙 기반 등록Convention-based registration

ASP.NET Core 앱에서 사용할 수 있는 타사 컨테이너는 다음과 같습니다.The following third-party containers can be used with ASP.NET Core apps:

스레드로부터의 안전성Thread safety

스레드로부터 안전한 싱글톤 서비스를 만듭니다.Create thread-safe singleton services. 싱글톤 서비스가 Transient 서비스에 대한 종속성을 갖는 경우 Transient 서비스는 싱글톤에서 사용되는 방식에 따라 스레드로부터 안전성이 필요할 수 있습니다.If a singleton service has a dependency on a transient service, the transient service may also require thread safety depending how it's used by the singleton.

AddSingleton<TService>(IServiceCollection, Func<IServiceProvider,TService>)의 두 번째 인수와 같은 단일 서비스의 팩터리 메서드는 스레드로부터 안전하지 않아도 됩니다.The factory method of single service, such as the second argument to AddSingleton<TService>(IServiceCollection, Func<IServiceProvider,TService>), doesn't need to be thread-safe. 형식(static) 생성자와 같이 이 메서드는 단일 스레드에서 한 번만 호출됩니다.Like a type (static) constructor, it's guaranteed to be called once by a single thread.

권장 사항Recommendations

  • async/awaitTask 기반 서비스 해결은 지원되지 않습니다.async/await and Task based service resolution is not supported. C#은 비동기 생성자를 지원하지 않으므로, 서비스를 동기식으로 해결한 후 비동기 메서드를 사용하는 패턴이 좋습니다.C# does not support asynchronous constructors; therefore, the recommended pattern is to use asynchronous methods after synchronously resolving the service.

  • 데이터 및 구성을 서비스 컨테이너에 직접 저장하지 마세요.Avoid storing data and configuration directly in the service container. 예를 들어 사용자의 쇼핑 카트는 일반적으로 서비스 컨테이너에 추가하지 말아야 합니다.For example, a user's shopping cart shouldn't typically be added to the service container. 구성은 옵션 패턴을 사용해야 합니다.Configuration should use the options pattern. 마찬가지로 다른 일부 개체에 대한 액세스를 허용하기 위해서만 존재하는 “데이터 보유자” 개체를 사용하지 마십시오.Similarly, avoid "data holder" objects that only exist to allow access to some other object. DI를 통해 실제 항목을 요청하는 것이 좋습니다.It's better to request the actual item via DI.

  • 서비스에 정적 액세스를 사용하지 마십시오.Avoid static access to services. 예를 들어 다른 곳에 사용하기 위해 IApplicationBuilder.ApplicationServices를 정적으로 입력하지 마세요.For example, avoid statically-typing IApplicationBuilder.ApplicationServices for use elsewhere.

  • ‘서비스 로케이터 패턴’은 Inversion of Control 전략을 혼합하므로 사용하지 마세요.Avoid using the service locator pattern, which mixes Inversion of Control strategies.

    • DI를 대신 사용할 수 있는 경우에는 GetService를 호출하여 서비스 인스턴스를 가져오지 마세요.Don't invoke GetService to obtain a service instance when you can use DI instead:

      잘못된 예:Incorrect:

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

      올바른 예:Correct:

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

  • HttpContext(예: IHttpContextAccessor.HttpContext)에 정적으로 액세스하지 마세요.Avoid static access to HttpContext (for example, IHttpContextAccessor.HttpContext).

모든 권장 사항과 마찬가지로, 권장 사항을 무시해야 하는 상황이 발생할 수 있습니다.Like all sets of recommendations, you may encounter situations where ignoring a recommendation is required. 예외는 드물게 발생하며 대부분 프레임워크 자체 내에서 특별한 경우에만 발생합니다.Exceptions are rare, mostly special cases within the framework itself.

DI는 정적/전역 개체 액세스 패턴의 ‘대안’입니다.DI is an alternative to static/global object access patterns. 고정 개체 액세스와 함께 사용할 경우 DI의 장점을 실현할 수 없습니다.You may not be able to realize the benefits of DI if you mix it with static object access.

추가 리소스Additional resources