ASP.NET Core에서 종속성 주입
참고 항목
이 문서의 최신 버전은 아닙니다. 현재 릴리스는 이 문서의 .NET 8 버전을 참조 하세요.
Important
이 정보는 상업적으로 출시되기 전에 실질적으로 수정될 수 있는 시험판 제품과 관련이 있습니다. Microsoft는 여기에 제공된 정보에 대해 어떠한 명시적, 또는 묵시적인 보증을 하지 않습니다.
현재 릴리스는 이 문서의 .NET 8 버전을 참조 하세요.
작성자: Kirk Larkin, Steve Smith, Brandon Dahler
ASP.NET Core는 클래스와 해당 종속성 간의 IoC(Inversion of Control)를 실현하는 기술인 DI(종속성 주입) 소프트웨어 디자인 패턴을 지원합니다.
MVC 컨트롤러 내의 종속성 주입에 대한 자세한 내용은 ASP.NET Core의 컨트롤러에 종속성 주입을 참조하세요.
웹앱이 아닌 애플리케이션에서 종속성 주입을 사용하는 방법에 대한 자세한 내용은 .NET의 종속성 주입을 참조하세요.
옵션의 종속성 주입에 대한 자세한 내용은 ASP.NET Core의 옵션 패턴을 참조하세요.
이 항목에서는 ASP.NET Core의 종속성 삽입에 관한 정보를 제공합니다. 종속성 주입 사용에 대한 기본 설명서는 .NET의 종속성 주입에 포함되어 있습니다.
Blazor 이 문서의 지침을 추가하거나 대체하는 DI 지침은 ASP.NET Core Blazor 종속성 주입을 참조하세요.
종속성 주입 개요
‘종속성’은 다른 개체가 종속된 개체입니다. 다른 클래스가 종속된 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");
}
}
이 클래스는 MyDependency
클래스를 만들고 이 클래스에 직접 종속됩니다. 이전 예제와 같은 코드 종속성은 문제가 있으며 다음과 같은 이유로 사용하지 않아야 합니다.
MyDependency
를 다른 구현으로 바꾸려면IndexModel
클래스를 수정해야 합니다.MyDependency
에 종속성이 있으면IndexModel
클래스에서 해당 종속성도 구성해야 합니다. 여러 클래스가MyDependency
에 종속되어 있는 대형 프로젝트에서는 구성 코드가 앱 전체에 분산됩니다.- 이 구현은 단위 테스트하기가 어렵습니다.
종속성 주입은 다음을 통해 이러한 문제를 해결합니다.
- 인퍼테이스 또는 기본 클래스를 사용하여 종속성 구현을 추상화합니다.
- 서비스 컨테이너에 종속성 등록. ASP.NET Core는 서비스 컨테이너인 IServiceProvider를 기본 제공합니다. 서비스는 일반적으로 앱의
Program.cs
파일에 등록됩니다. - 서비스가 사용되는 클래스의 생성자에 주입됨. 프레임워크가 종속성의 인스턴스를 만들고 더 이상 필요하지 않으면 삭제하는 작업을 담당합니다.
샘플 앱에서 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 메서드는 단일 요청의 수명인 범위가 지정된 수명으로 서비스를 등록합니다. 서비스 수명에 대해서는 이 항목의 뒷부분에서 설명합니다.
using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddScoped<IMyDependency, MyDependency>();
var app = builder.Build();
샘플 앱에서는 IMyDependency
서비스가 요청되며 이 서비스는 WriteMessage
메서드를 호출하는 데 사용됩니다.
public class Index2Model : PageModel
{
private readonly IMyDependency _myDependency;
public Index2Model(IMyDependency myDependency)
{
_myDependency = myDependency;
}
public void OnGet()
{
_myDependency.WriteMessage("Index2Model.OnGet");
}
}
DI 패턴을 사용하면 컨트롤러 또는 Razor 페이지는 다음과 같이 작동합니다.
- 컨트롤러는 구체적인 형식
MyDependency
를 사용하지 않고 구현되는IMyDependency
인터페이스만 사용합니다. 따라서 컨트롤러 또는 Razor 페이지를 수정하지 않고 구현을 쉽게 변경할 수 있습니다. 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}");
}
}
업데이트된 Program.cs
는 새 IMyDependency
구현을 등록합니다.
using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddScoped<IMyDependency, MyDependency2>();
var app = builder.Build();
MyDependency2
는 생성자에서 요청하는 ILogger<TCategoryName>에 종속됩니다. ILogger<TCategoryName>
은 프레임워크에서 제공하는 서비스입니다.
종속성 주입을 연결된 방식으로 사용하는 일은 특별한 경우가 아닙니다. 요청된 각 종속성은 차례로 자체 종속성을 요청합니다. 컨테이너는 그래프의 종속성을 해결하고 완전히 해결된 서비스를 반환합니다. 해결해야 하는 종속성이 모인 집합은 일반적으로 종속성 트리, 종속성 그래프 또는 개체 그래프라고 합니다.
컨테이너는 개방형 형식(제네릭)을 활용하여 ILogger<TCategoryName>
을 해결하므로 모든 생성된 형식(제네릭)을 등록하지 않아도 됩니다.
종속성 주입 용어에서 서비스는 다음과 같습니다.
- 일반적으로 다른 개체에
IMyDependency
서비스와 같은 서비스를 제공하는 개체입니다. - 서비스에서 웹 서비스를 사용할 수 있지만 웹 서비스와 관련 있는 것은 아닙니다.
해당 프레임워크는 강력한 로깅 시스템을 제공합니다. 이전 예제에 표시된 IMyDependency
구현은 로깅을 구현하는 것이 아니라 기본 DI를 보여 주기 위해 작성되었습니다. 대부분의 앱에서는 로거를 작성할 필요가 없습니다. 다음 코드에서는 서비스를 등록하지 않아도 되는 기본 로깅을 사용하는 방법을 보여 줍니다.
public class AboutModel : PageModel
{
private readonly ILogger _logger;
public AboutModel(ILogger<AboutModel> logger)
{
_logger = logger;
}
public string Message { get; set; } = string.Empty;
public void OnGet()
{
Message = $"About page visited at {DateTime.UtcNow.ToLongTimeString()}";
_logger.LogInformation(Message);
}
}
위의 코드를 사용하여 프레임워크에서 로깅을 제공하므로 Program.cs
를 업데이트할 필요가 없습니다.
확장 메서드를 사용하여 서비스 그룹 등록
ASP.NET Core 프레임워크에서는 관련 서비스 그룹을 등록하는 규칙을 사용합니다. 규칙은 단일 Add{GROUP_NAME}
확장 메서드를 사용하여 프레임워크 기능에 필요한 모든 서비스를 등록하는 것입니다. 예를 들어 AddControllers 확장 메서드는 MVC 컨트롤러에 필요한 서비스를 등록합니다.
다음 코드는 개별 사용자 계정을 사용하는 Razor Pages 템플릿으로 생성되며 확장 메서드 AddDbContext 및 AddDefaultIdentity를 사용하여 컨테이너에 서비스를 추가하는 방법을 보여 줍니다.
using DependencyInjectionSample.Data;
using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;
var builder = WebApplication.CreateBuilder(args);
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();
builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
.AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();
var app = builder.Build();
서비스를 등록하고 옵션을 구성하는 다음 메서드를 고려합니다.
using ConfigSample.Options;
using Microsoft.Extensions.DependencyInjection.ConfigSample.Options;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.Configure<PositionOptions>(
builder.Configuration.GetSection(PositionOptions.Position));
builder.Services.Configure<ColorOptions>(
builder.Configuration.GetSection(ColorOptions.Color));
builder.Services.AddScoped<IMyDependency, MyDependency>();
builder.Services.AddScoped<IMyDependency2, MyDependency2>();
var app = builder.Build();
관련 등록 그룹을 확장 메서드로 이동하여 서비스를 등록할 수 있습니다. 예를 들어, 구성 서비스는 다음 클래스에 추가됩니다.
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;
}
public static IServiceCollection AddMyDependencyGroup(
this IServiceCollection services)
{
services.AddScoped<IMyDependency, MyDependency>();
services.AddScoped<IMyDependency2, MyDependency2>();
return services;
}
}
}
나머지 서비스는 유사한 클래스에 등록됩니다. 다음 코드는 새 확장 메서드를 사용하여 서비스를 등록합니다.
using Microsoft.Extensions.DependencyInjection.ConfigSample.Options;
var builder = WebApplication.CreateBuilder(args);
builder.Services
.AddConfig(builder.Configuration)
.AddMyDependencyGroup();
builder.Services.AddRazorPages();
var app = builder.Build();
참고: 각 services.Add{GROUP_NAME}
확장 메서드는 서비스를 추가하고 잠재적으로 구성합니다. 예를 들어 AddControllersWithViews는 보기에 필요한 서비스 MVC 컨트롤러를 추가하고 AddRazorPages는 Razor Pages에 필요한 서비스를 추가합니다.
서비스 수명
.NET의 종속성 주입의 서비스 수명을 참조하세요.
미들웨어에서 범위 지정 서비스를 사용하려면 다음 방법 중 하나를 사용합니다.
- 미들웨어의
Invoke
또는InvokeAsync
메서드에 서비스를 삽입합니다. 생성자 주입을 사용하면 범위 지정 서비스가 싱글톤처럼 작동하게 하므로 런타임 예외가 throw됩니다. 수명 및 등록 옵션 섹션의 샘플에서는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);
}
}
키 지정 서비스
키 서비스는 키를 사용하여 DI(종속성 주입) 서비스를 등록하고 검색하는 메커니즘을 나타냅니다. 서비스는 키를 등록하기 위해 호출 AddKeyedSingleton (또는 AddKeyedScoped
AddKeyedTransient
)하여 키와 연결됩니다. 특성을 사용하여 키를 [FromKeyedServices]
지정하여 등록된 서비스에 액세스합니다. 다음 코드는 키 지정된 서비스를 사용하는 방법을 보여 줍니다.
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.SignalR;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddKeyedSingleton<ICache, BigCache>("big");
builder.Services.AddKeyedSingleton<ICache, SmallCache>("small");
builder.Services.AddControllers();
var app = builder.Build();
app.MapGet("/big", ([FromKeyedServices("big")] ICache bigCache) => bigCache.Get("date"));
app.MapGet("/small", ([FromKeyedServices("small")] ICache smallCache) =>
smallCache.Get("date"));
app.MapControllers();
app.Run();
public interface ICache
{
object Get(string key);
}
public class BigCache : ICache
{
public object Get(string key) => $"Resolving {key} from big cache.";
}
public class SmallCache : ICache
{
public object Get(string key) => $"Resolving {key} from small cache.";
}
[ApiController]
[Route("/cache")]
public class CustomServicesApiController : Controller
{
[HttpGet("big-cache")]
public ActionResult<object> GetOk([FromKeyedServices("big")] ICache cache)
{
return cache.Get("data-mvc");
}
}
public class MyHub : Hub
{
public void Method([FromKeyedServices("small")] ICache cache)
{
Console.WriteLine(cache.Get("signalr"));
}
}
미들웨어의 키 지정된 서비스
미들웨어는 생성자와 Invoke
/InvokeAsync
메서드 모두에서 Keyed 서비스를 지원합니다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddKeyedSingleton<MySingletonClass>("test");
builder.Services.AddKeyedScoped<MyScopedClass>("test2");
var app = builder.Build();
app.UseMiddleware<MyMiddleware>();
app.Run();
internal class MyMiddleware
{
private readonly RequestDelegate _next;
public MyMiddleware(RequestDelegate next,
[FromKeyedServices("test")] MySingletonClass service)
{
_next = next;
}
public Task Invoke(HttpContext context,
[FromKeyedServices("test2")]
MyScopedClass scopedService) => _next(context);
}
미들웨어를 만드는 방법에 대한 자세한 내용은 사용자 지정 ASP.NET Core 미들웨어 작성을 참조 하세요.
생성자 주입 동작
.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; }
}
다음 코드는 명명된 수명에 따라 Operation
클래스의 여러 등록을 만듭니다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddTransient<IOperationTransient, Operation>();
builder.Services.AddScoped<IOperationScoped, Operation>();
builder.Services.AddSingleton<IOperationSingleton, Operation>();
var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseMyMiddleware();
app.UseRouting();
app.UseAuthorization();
app.MapRazorPages();
app.Run();
샘플 앱에서는 요청 내의 개체 수명과 요청 간의 개체 수명을 모두 보여 줍니다. 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 IOperationSingleton _singletonOperation;
public MyMiddleware(RequestDelegate next, ILogger<MyMiddleware> logger,
IOperationSingleton singletonOperation)
{
_logger = logger;
_singletonOperation = singletonOperation;
_next = next;
}
public async Task InvokeAsync(HttpContext context,
IOperationTransient transientOperation, 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,
IOperationTransient transientOperation, IOperationScoped scopedOperation)
{
_logger.LogInformation("Transient: " + transientOperation.OperationId);
_logger.LogInformation("Scoped: " + scopedOperation.OperationId);
_logger.LogInformation("Singleton: " + _singletonOperation.OperationId);
await _next(context);
}
로거 출력은 다음을 보여 줍니다.
- Transient 개체는 항상 다릅니다. 임시
OperationId
값은IndexModel
과 미들웨어에서 다릅니다. - Scoped 개체는 제공된 요청에 대해 동일하지만 각각의 새 요청 간에는 다릅니다.
- ‘싱글톤’ 개체는 모든 요청에 동일합니다.
로깅 출력을 줄이려면 appsettings.Development.json
파일에서 "Logging:LogLevel:Microsoft:Error"를 설정합니다.
{
"MyKey": "MyKey from appsettings.Developement.json",
"Logging": {
"LogLevel": {
"Default": "Information",
"System": "Debug",
"Microsoft": "Error"
}
}
}
앱 시작 시 서비스 확인
다음 코드는 앱이 시작될 때 제한된 기간 동안 범위가 지정된 서비스를 확인하는 방법을 보여 줍니다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddScoped<IMyDependency, MyDependency>();
var app = builder.Build();
using (var serviceScope = app.Services.CreateScope())
{
var services = serviceScope.ServiceProvider;
var myDependency = services.GetRequiredService<IMyDependency>();
myDependency.WriteMessage("Call services from main");
}
app.MapGet("/", () => "Hello World!");
app.Run();
범위 유효성 검사
.NET의 종속성 주입의 생성자 주입 동작을 참조하세요.
자세한 내용은 범위 유효성 검사를 참조하세요.
요청 서비스
ASP.NET Core 요청 내의 서비스 및 해당 종속성은 HttpContext.RequestServices을 통해 노출됩니다.
프레임워크는 요청당 범위를 만들고 RequestServices
는 범위가 지정된 서비스 공급자를 공개합니다. 범위가 지정된 모든 서비스는 요청이 활성 상태인 동안 유효합니다.
참고 항목
RequestServices
에서 서비스를 확인하는 것보다 생성자 매개 변수로 종속성을 요청하는 것을 선호합니다. 생성자 매개 변수로 종속성을 요청하면 테스트하기 쉬운 클래스가 생성됩니다.
종속성 주입을 위한 서비스 디자인
종속성 주입을 위한 서비스를 디자인하는 경우
- 상태 저장 정적 클래스 및 멤버를 사용하지 마세요. 대신 싱글톤 서비스를 사용하도록 앱을 설계하여 전역 상태를 만들지 않도록 합니다.
- 서비스 내의 종속 클래스를 직접 인스턴스화하지 마세요. 직접 인스턴스화는 코드를 특정 구현에 결합합니다.
- 서비스를 작고 잘 구성되고 쉽게 테스트할 수 있도록 만듭니다.
클래스에 주입된 종속성이 많은 경우 클래스에 역할이 너무 많고 SRP(단일 책임 원칙)를 위반하는 것일 수 있습니다. 해당 책임 몇 가지를 새로운 클래스로 이동하여 클래스를 리팩터링해 보세요. Razor Pages의 페이지 모델 클래스 및 MVC 컨트롤러 클래스는 UI 고려 사항에 집중해야 합니다.
서비스 삭제
컨테이너는 자신이 만든 IDisposable 형식에 대해 Dispose를 호출합니다. 개발자는 컨테이너에서 확인된 서비스는 삭제해서는 안 됩니다. 형식 또는 팩터리가 싱글톤으로 등록된 경우 컨테이너에서 싱글톤을 자동으로 삭제합니다.
다음 예제에서 서비스는 서비스 컨테이너에 의해 생성되고 자동으로 삭제됩니다. dependency-injection\samples\6.x\DIsample2\DIsample2\Services\Service1.cs
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;
}
}
using DIsample2.Services;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddScoped<Service1>();
builder.Services.AddSingleton<Service2>();
var myKey = builder.Configuration["MyKey"];
builder.Services.AddSingleton<IService3>(sp => new Service3(myKey));
var app = builder.Build();
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, MyKey = MyKey from appsettings.Developement.json
Service1.Dispose
서비스 컨테이너에서 만들지 않은 서비스
다음 코드를 생각해 봅시다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddSingleton(new Service1());
builder.Services.AddSingleton(new Service2());
위의 코드에서
- 서비스 인스턴스가 서비스 컨테이너에 의해 만들어지지 않습니다.
- 프레임워크가 서비스를 자동으로 삭제하지 않습니다.
- 개발자가 서비스 삭제를 담당합니다.
임시 및 공유 인스턴스에 대한 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)에 정적으로 액세스하지 마세요.
DI는 정적/전역 개체 액세스 패턴의 ‘대안’입니다. 고정 개체 액세스와 함께 사용할 경우 DI의 장점을 실현할 수 없습니다.
DI의 다중 테넌트에 권장되는 패턴
Orchard Core는 ASP.NET Core에서 모듈식 다중 테넌트 애플리케이션을 빌드하기 위한 애플리케이션 프레임워크입니다. 자세한 내용은 Orchard Core 설명서를 참조하세요.
CMS 고유 기능 없이 Orchard Core Framework를 사용하여 모듈식 다중 테넌트 앱을 빌드하는 방법에 대한 예제는 Orchard Core 샘플을 참조하세요.
프레임워크에서 제공하는 서비스
Program.cs
는 Entity Framework Core, ASP.NET Core MVC 등의 플랫폼 기능을 비롯해 앱이 사용하는 서비스를 등록합니다. 처음에 Program.cs
에 제공되는 IServiceCollection
에는 호스트가 구성된 방법에 따라 달라지는 프레임워크에 의해 정의되는 서비스가 있습니다. ASP.NET Core 템플릿을 기반으로 하는 앱의 경우 프레임워크에서 250개 이상의 서비스를 등록합니다.
다음 표에는 프레임워크에서 등록한 서비스들의 작은 샘플이 나열되어 있습니다.
추가 리소스
- ASP.NET Core의 뷰에 종속성 주입
- ASP.NET Core의 컨트롤러에 종속성 주입
- ASP.NET Core의 요구 사항 처리기에서 종속성 주입
- ASP.NET Core Blazor 종속성 주입
- DI 앱 개발을 위한 NDC 컨퍼런스 패턴
- ASP.NET Core의 앱 시작
- ASP.NET Core의 팩터리 기반 미들웨어 활성화
- .NET의 종속성 주입 기본 사항 이해
- 종속성 주입 지침
- 자습서: .NET에서 종속성 주입 사용
- .NET 종속성 주입
- ASP.NET 핵심 종속성 주입: ISERVICECOLLECTION이란?
- IDisposables in ASP.NET Core를 삭제하는 네 가지 방법
- 종속성 주입으로 ASP.NET Core에 정리 코드 작성(MSDN)
- 명시적 종속성 원칙
- Inversion of Control 컨테이너 및 종속성 주입 패턴(Martin Fowler)
- How to register a service with multiple interfaces in ASP.NET Core DI(ASP.NET Core DI의 여러 인터페이스를 사용하여 서비스를 등록하는 방법)
작성자: Kirk Larkin, Steve Smith, Brandon 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");
}
}
이 클래스는 MyDependency
클래스를 만들고 이 클래스에 직접 종속됩니다. 이전 예제와 같은 코드 종속성은 문제가 있으며 다음과 같은 이유로 사용하지 않아야 합니다.
MyDependency
를 다른 구현으로 바꾸려면IndexModel
클래스를 수정해야 합니다.MyDependency
에 종속성이 있으면IndexModel
클래스에서 해당 종속성도 구성해야 합니다. 여러 클래스가MyDependency
에 종속되어 있는 대형 프로젝트에서는 구성 코드가 앱 전체에 분산됩니다.- 이 구현은 단위 테스트하기가 어렵습니다.
종속성 주입은 다음을 통해 이러한 문제를 해결합니다.
- 인퍼테이스 또는 기본 클래스를 사용하여 종속성 구현을 추상화합니다.
- 서비스 컨테이너에 종속성 등록. ASP.NET Core는 서비스 컨테이너인 IServiceProvider를 기본 제공합니다. 서비스는 일반적으로 앱의
Program.cs
파일에 등록됩니다. - 서비스가 사용되는 클래스의 생성자에 주입됨. 프레임워크가 종속성의 인스턴스를 만들고 더 이상 필요하지 않으면 삭제하는 작업을 담당합니다.
샘플 앱에서 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 메서드는 단일 요청의 수명인 범위가 지정된 수명으로 서비스를 등록합니다. 서비스 수명에 대해서는 이 항목의 뒷부분에서 설명합니다.
using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddScoped<IMyDependency, MyDependency>();
var app = builder.Build();
샘플 앱에서는 IMyDependency
서비스가 요청되며 이 서비스는 WriteMessage
메서드를 호출하는 데 사용됩니다.
public class Index2Model : PageModel
{
private readonly IMyDependency _myDependency;
public Index2Model(IMyDependency myDependency)
{
_myDependency = myDependency;
}
public void OnGet()
{
_myDependency.WriteMessage("Index2Model.OnGet");
}
}
DI 패턴을 사용하면 컨트롤러 또는 Razor 페이지는 다음과 같이 작동합니다.
- 컨트롤러는 구체적인 형식
MyDependency
를 사용하지 않고 구현되는IMyDependency
인터페이스만 사용합니다. 따라서 컨트롤러 또는 Razor 페이지를 수정하지 않고 구현을 쉽게 변경할 수 있습니다. 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}");
}
}
업데이트된 Program.cs
는 새 IMyDependency
구현을 등록합니다.
using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddScoped<IMyDependency, MyDependency2>();
var app = builder.Build();
MyDependency2
는 생성자에서 요청하는 ILogger<TCategoryName>에 종속됩니다. ILogger<TCategoryName>
은 프레임워크에서 제공하는 서비스입니다.
종속성 주입을 연결된 방식으로 사용하는 일은 특별한 경우가 아닙니다. 요청된 각 종속성은 차례로 자체 종속성을 요청합니다. 컨테이너는 그래프의 종속성을 해결하고 완전히 해결된 서비스를 반환합니다. 해결해야 하는 종속성이 모인 집합은 일반적으로 종속성 트리, 종속성 그래프 또는 개체 그래프라고 합니다.
컨테이너는 개방형 형식(제네릭)을 활용하여 ILogger<TCategoryName>
을 해결하므로 모든 생성된 형식(제네릭)을 등록하지 않아도 됩니다.
종속성 주입 용어에서 서비스는 다음과 같습니다.
- 일반적으로 다른 개체에
IMyDependency
서비스와 같은 서비스를 제공하는 개체입니다. - 서비스에서 웹 서비스를 사용할 수 있지만 웹 서비스와 관련 있는 것은 아닙니다.
해당 프레임워크는 강력한 로깅 시스템을 제공합니다. 이전 예제에 표시된 IMyDependency
구현은 로깅을 구현하는 것이 아니라 기본 DI를 보여 주기 위해 작성되었습니다. 대부분의 앱에서는 로거를 작성할 필요가 없습니다. 다음 코드에서는 서비스를 등록하지 않아도 되는 기본 로깅을 사용하는 방법을 보여 줍니다.
public class AboutModel : PageModel
{
private readonly ILogger _logger;
public AboutModel(ILogger<AboutModel> logger)
{
_logger = logger;
}
public string Message { get; set; } = string.Empty;
public void OnGet()
{
Message = $"About page visited at {DateTime.UtcNow.ToLongTimeString()}";
_logger.LogInformation(Message);
}
}
위의 코드를 사용하여 프레임워크에서 로깅을 제공하므로 Program.cs
를 업데이트할 필요가 없습니다.
확장 메서드를 사용하여 서비스 그룹 등록
ASP.NET Core 프레임워크에서는 관련 서비스 그룹을 등록하는 규칙을 사용합니다. 규칙은 단일 Add{GROUP_NAME}
확장 메서드를 사용하여 프레임워크 기능에 필요한 모든 서비스를 등록하는 것입니다. 예를 들어 AddControllers 확장 메서드는 MVC 컨트롤러에 필요한 서비스를 등록합니다.
다음 코드는 개별 사용자 계정을 사용하는 Razor Pages 템플릿으로 생성되며 확장 메서드 AddDbContext 및 AddDefaultIdentity를 사용하여 컨테이너에 서비스를 추가하는 방법을 보여 줍니다.
using DependencyInjectionSample.Data;
using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;
var builder = WebApplication.CreateBuilder(args);
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();
builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
.AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();
var app = builder.Build();
서비스를 등록하고 옵션을 구성하는 다음 메서드를 고려합니다.
using ConfigSample.Options;
using Microsoft.Extensions.DependencyInjection.ConfigSample.Options;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.Configure<PositionOptions>(
builder.Configuration.GetSection(PositionOptions.Position));
builder.Services.Configure<ColorOptions>(
builder.Configuration.GetSection(ColorOptions.Color));
builder.Services.AddScoped<IMyDependency, MyDependency>();
builder.Services.AddScoped<IMyDependency2, MyDependency2>();
var app = builder.Build();
관련 등록 그룹을 확장 메서드로 이동하여 서비스를 등록할 수 있습니다. 예를 들어, 구성 서비스는 다음 클래스에 추가됩니다.
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;
}
public static IServiceCollection AddMyDependencyGroup(
this IServiceCollection services)
{
services.AddScoped<IMyDependency, MyDependency>();
services.AddScoped<IMyDependency2, MyDependency2>();
return services;
}
}
}
나머지 서비스는 유사한 클래스에 등록됩니다. 다음 코드는 새 확장 메서드를 사용하여 서비스를 등록합니다.
using Microsoft.Extensions.DependencyInjection.ConfigSample.Options;
var builder = WebApplication.CreateBuilder(args);
builder.Services
.AddConfig(builder.Configuration)
.AddMyDependencyGroup();
builder.Services.AddRazorPages();
var app = builder.Build();
참고: 각 services.Add{GROUP_NAME}
확장 메서드는 서비스를 추가하고 잠재적으로 구성합니다. 예를 들어 AddControllersWithViews는 보기에 필요한 서비스 MVC 컨트롤러를 추가하고 AddRazorPages는 Razor Pages에 필요한 서비스를 추가합니다.
서비스 수명
.NET의 종속성 주입의 서비스 수명을 참조하세요.
미들웨어에서 범위 지정 서비스를 사용하려면 다음 방법 중 하나를 사용합니다.
- 미들웨어의
Invoke
또는InvokeAsync
메서드에 서비스를 삽입합니다. 생성자 주입을 사용하면 범위 지정 서비스가 싱글톤처럼 작동하게 하므로 런타임 예외가 throw됩니다. 수명 및 등록 옵션 섹션의 샘플에서는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);
}
}
키 지정 서비스
키 서비스는 키를 사용하여 DI(종속성 주입) 서비스를 등록하고 검색하는 메커니즘을 나타냅니다. 서비스는 키를 등록하기 위해 호출 AddKeyedSingleton (또는 AddKeyedScoped
AddKeyedTransient
)하여 키와 연결됩니다. 특성을 사용하여 키를 [FromKeyedServices]
지정하여 등록된 서비스에 액세스합니다. 다음 코드는 키 지정된 서비스를 사용하는 방법을 보여 줍니다.
using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.SignalR;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddKeyedSingleton<ICache, BigCache>("big");
builder.Services.AddKeyedSingleton<ICache, SmallCache>("small");
builder.Services.AddControllers();
var app = builder.Build();
app.MapGet("/big", ([FromKeyedServices("big")] ICache bigCache) => bigCache.Get("date"));
app.MapGet("/small", ([FromKeyedServices("small")] ICache smallCache) =>
smallCache.Get("date"));
app.MapControllers();
app.Run();
public interface ICache
{
object Get(string key);
}
public class BigCache : ICache
{
public object Get(string key) => $"Resolving {key} from big cache.";
}
public class SmallCache : ICache
{
public object Get(string key) => $"Resolving {key} from small cache.";
}
[ApiController]
[Route("/cache")]
public class CustomServicesApiController : Controller
{
[HttpGet("big-cache")]
public ActionResult<object> GetOk([FromKeyedServices("big")] ICache cache)
{
return cache.Get("data-mvc");
}
}
public class MyHub : Hub
{
public void Method([FromKeyedServices("small")] ICache cache)
{
Console.WriteLine(cache.Get("signalr"));
}
}
생성자 주입 동작
.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; }
}
다음 코드는 명명된 수명에 따라 Operation
클래스의 여러 등록을 만듭니다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddTransient<IOperationTransient, Operation>();
builder.Services.AddScoped<IOperationScoped, Operation>();
builder.Services.AddSingleton<IOperationSingleton, Operation>();
var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseMyMiddleware();
app.UseRouting();
app.UseAuthorization();
app.MapRazorPages();
app.Run();
샘플 앱에서는 요청 내의 개체 수명과 요청 간의 개체 수명을 모두 보여 줍니다. 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 IOperationSingleton _singletonOperation;
public MyMiddleware(RequestDelegate next, ILogger<MyMiddleware> logger,
IOperationSingleton singletonOperation)
{
_logger = logger;
_singletonOperation = singletonOperation;
_next = next;
}
public async Task InvokeAsync(HttpContext context,
IOperationTransient transientOperation, 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,
IOperationTransient transientOperation, IOperationScoped scopedOperation)
{
_logger.LogInformation("Transient: " + transientOperation.OperationId);
_logger.LogInformation("Scoped: " + scopedOperation.OperationId);
_logger.LogInformation("Singleton: " + _singletonOperation.OperationId);
await _next(context);
}
로거 출력은 다음을 보여 줍니다.
- Transient 개체는 항상 다릅니다. 임시
OperationId
값은IndexModel
과 미들웨어에서 다릅니다. - Scoped 개체는 제공된 요청에 대해 동일하지만 각각의 새 요청 간에는 다릅니다.
- ‘싱글톤’ 개체는 모든 요청에 동일합니다.
로깅 출력을 줄이려면 appsettings.Development.json
파일에서 "Logging:LogLevel:Microsoft:Error"를 설정합니다.
{
"MyKey": "MyKey from appsettings.Developement.json",
"Logging": {
"LogLevel": {
"Default": "Information",
"System": "Debug",
"Microsoft": "Error"
}
}
}
앱 시작 시 서비스 확인
다음 코드는 앱이 시작될 때 제한된 기간 동안 범위가 지정된 서비스를 확인하는 방법을 보여 줍니다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddScoped<IMyDependency, MyDependency>();
var app = builder.Build();
using (var serviceScope = app.Services.CreateScope())
{
var services = serviceScope.ServiceProvider;
var myDependency = services.GetRequiredService<IMyDependency>();
myDependency.WriteMessage("Call services from main");
}
app.MapGet("/", () => "Hello World!");
app.Run();
범위 유효성 검사
.NET의 종속성 주입의 생성자 주입 동작을 참조하세요.
자세한 내용은 범위 유효성 검사를 참조하세요.
요청 서비스
ASP.NET Core 요청 내의 서비스 및 해당 종속성은 HttpContext.RequestServices을 통해 노출됩니다.
프레임워크는 요청당 범위를 만들고 RequestServices
는 범위가 지정된 서비스 공급자를 공개합니다. 범위가 지정된 모든 서비스는 요청이 활성 상태인 동안 유효합니다.
참고 항목
RequestServices
에서 서비스를 확인하는 것보다 생성자 매개 변수로 종속성을 요청하는 것을 선호합니다. 생성자 매개 변수로 종속성을 요청하면 테스트하기 쉬운 클래스가 생성됩니다.
종속성 주입을 위한 서비스 디자인
종속성 주입을 위한 서비스를 디자인하는 경우
- 상태 저장 정적 클래스 및 멤버를 사용하지 마세요. 대신 싱글톤 서비스를 사용하도록 앱을 설계하여 전역 상태를 만들지 않도록 합니다.
- 서비스 내의 종속 클래스를 직접 인스턴스화하지 마세요. 직접 인스턴스화는 코드를 특정 구현에 결합합니다.
- 서비스를 작고 잘 구성되고 쉽게 테스트할 수 있도록 만듭니다.
클래스에 주입된 종속성이 많은 경우 클래스에 역할이 너무 많고 SRP(단일 책임 원칙)를 위반하는 것일 수 있습니다. 해당 책임 몇 가지를 새로운 클래스로 이동하여 클래스를 리팩터링해 보세요. Razor Pages의 페이지 모델 클래스 및 MVC 컨트롤러 클래스는 UI 고려 사항에 집중해야 합니다.
서비스 삭제
컨테이너는 자신이 만든 IDisposable 형식에 대해 Dispose를 호출합니다. 개발자는 컨테이너에서 확인된 서비스는 삭제해서는 안 됩니다. 형식 또는 팩터리가 싱글톤으로 등록된 경우 컨테이너에서 싱글톤을 자동으로 삭제합니다.
다음 예제에서 서비스는 서비스 컨테이너에 의해 생성되고 자동으로 삭제됩니다. dependency-injection\samples\6.x\DIsample2\DIsample2\Services\Service1.cs
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;
}
}
using DIsample2.Services;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddScoped<Service1>();
builder.Services.AddSingleton<Service2>();
var myKey = builder.Configuration["MyKey"];
builder.Services.AddSingleton<IService3>(sp => new Service3(myKey));
var app = builder.Build();
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, MyKey = MyKey from appsettings.Developement.json
Service1.Dispose
서비스 컨테이너에서 만들지 않은 서비스
다음 코드를 생각해 봅시다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddSingleton(new Service1());
builder.Services.AddSingleton(new Service2());
위의 코드에서
- 서비스 인스턴스가 서비스 컨테이너에 의해 만들어지지 않습니다.
- 프레임워크가 서비스를 자동으로 삭제하지 않습니다.
- 개발자가 서비스 삭제를 담당합니다.
임시 및 공유 인스턴스에 대한 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)에 정적으로 액세스하지 마세요.
DI는 정적/전역 개체 액세스 패턴의 ‘대안’입니다. 고정 개체 액세스와 함께 사용할 경우 DI의 장점을 실현할 수 없습니다.
DI의 다중 테넌트에 권장되는 패턴
Orchard Core는 ASP.NET Core에서 모듈식 다중 테넌트 애플리케이션을 빌드하기 위한 애플리케이션 프레임워크입니다. 자세한 내용은 Orchard Core 설명서를 참조하세요.
CMS 고유 기능 없이 Orchard Core Framework를 사용하여 모듈식 다중 테넌트 앱을 빌드하는 방법에 대한 예제는 Orchard Core 샘플을 참조하세요.
프레임워크에서 제공하는 서비스
Program.cs
는 Entity Framework Core, ASP.NET Core MVC 등의 플랫폼 기능을 비롯해 앱이 사용하는 서비스를 등록합니다. 처음에 Program.cs
에 제공되는 IServiceCollection
에는 호스트가 구성된 방법에 따라 달라지는 프레임워크에 의해 정의되는 서비스가 있습니다. ASP.NET Core 템플릿을 기반으로 하는 앱의 경우 프레임워크에서 250개 이상의 서비스를 등록합니다.
다음 표에는 프레임워크에서 등록한 서비스들의 작은 샘플이 나열되어 있습니다.
추가 리소스
- ASP.NET Core의 뷰에 종속성 주입
- ASP.NET Core의 컨트롤러에 종속성 주입
- ASP.NET Core의 요구 사항 처리기에서 종속성 주입
- ASP.NET Core Blazor 종속성 주입
- DI 앱 개발을 위한 NDC 컨퍼런스 패턴
- ASP.NET Core의 앱 시작
- ASP.NET Core의 팩터리 기반 미들웨어 활성화
- .NET의 종속성 주입 기본 사항 이해
- 종속성 주입 지침
- 자습서: .NET에서 종속성 주입 사용
- .NET 종속성 주입
- ASP.NET 핵심 종속성 주입: ISERVICECOLLECTION이란?
- IDisposables in ASP.NET Core를 삭제하는 네 가지 방법
- 종속성 주입으로 ASP.NET Core에 정리 코드 작성(MSDN)
- 명시적 종속성 원칙
- Inversion of Control 컨테이너 및 종속성 주입 패턴(Martin Fowler)
- How to register a service with multiple interfaces in ASP.NET Core DI(ASP.NET Core DI의 여러 인터페이스를 사용하여 서비스를 등록하는 방법)
작성자: Kirk Larkin, Steve Smith, Brandon 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");
}
}
이 클래스는 MyDependency
클래스를 만들고 이 클래스에 직접 종속됩니다. 이전 예제와 같은 코드 종속성은 문제가 있으며 다음과 같은 이유로 사용하지 않아야 합니다.
MyDependency
를 다른 구현으로 바꾸려면IndexModel
클래스를 수정해야 합니다.MyDependency
에 종속성이 있으면IndexModel
클래스에서 해당 종속성도 구성해야 합니다. 여러 클래스가MyDependency
에 종속되어 있는 대형 프로젝트에서는 구성 코드가 앱 전체에 분산됩니다.- 이 구현은 단위 테스트하기가 어렵습니다.
종속성 주입은 다음을 통해 이러한 문제를 해결합니다.
- 인퍼테이스 또는 기본 클래스를 사용하여 종속성 구현을 추상화합니다.
- 서비스 컨테이너에 종속성 등록. ASP.NET Core는 서비스 컨테이너인 IServiceProvider를 기본 제공합니다. 서비스는 일반적으로 앱의
Program.cs
파일에 등록됩니다. - 서비스가 사용되는 클래스의 생성자에 주입됨. 프레임워크가 종속성의 인스턴스를 만들고 더 이상 필요하지 않으면 삭제하는 작업을 담당합니다.
샘플 앱에서 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 메서드는 단일 요청의 수명인 범위가 지정된 수명으로 서비스를 등록합니다. 서비스 수명에 대해서는 이 항목의 뒷부분에서 설명합니다.
using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddScoped<IMyDependency, MyDependency>();
var app = builder.Build();
샘플 앱에서는 IMyDependency
서비스가 요청되며 이 서비스는 WriteMessage
메서드를 호출하는 데 사용됩니다.
public class Index2Model : PageModel
{
private readonly IMyDependency _myDependency;
public Index2Model(IMyDependency myDependency)
{
_myDependency = myDependency;
}
public void OnGet()
{
_myDependency.WriteMessage("Index2Model.OnGet");
}
}
DI 패턴을 사용하면 컨트롤러 또는 Razor 페이지는 다음과 같이 작동합니다.
- 컨트롤러는 구체적인 형식
MyDependency
를 사용하지 않고 구현되는IMyDependency
인터페이스만 사용합니다. 따라서 컨트롤러 또는 Razor 페이지를 수정하지 않고 구현을 쉽게 변경할 수 있습니다. 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}");
}
}
업데이트된 Program.cs
는 새 IMyDependency
구현을 등록합니다.
using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddScoped<IMyDependency, MyDependency2>();
var app = builder.Build();
MyDependency2
는 생성자에서 요청하는 ILogger<TCategoryName>에 종속됩니다. ILogger<TCategoryName>
은 프레임워크에서 제공하는 서비스입니다.
종속성 주입을 연결된 방식으로 사용하는 일은 특별한 경우가 아닙니다. 요청된 각 종속성은 차례로 자체 종속성을 요청합니다. 컨테이너는 그래프의 종속성을 해결하고 완전히 해결된 서비스를 반환합니다. 해결해야 하는 종속성이 모인 집합은 일반적으로 종속성 트리, 종속성 그래프 또는 개체 그래프라고 합니다.
컨테이너는 개방형 형식(제네릭)을 활용하여 ILogger<TCategoryName>
을 해결하므로 모든 생성된 형식(제네릭)을 등록하지 않아도 됩니다.
종속성 주입 용어에서 서비스는 다음과 같습니다.
- 일반적으로 다른 개체에
IMyDependency
서비스와 같은 서비스를 제공하는 개체입니다. - 서비스에서 웹 서비스를 사용할 수 있지만 웹 서비스와 관련 있는 것은 아닙니다.
해당 프레임워크는 강력한 로깅 시스템을 제공합니다. 이전 예제에 표시된 IMyDependency
구현은 로깅을 구현하는 것이 아니라 기본 DI를 보여 주기 위해 작성되었습니다. 대부분의 앱에서는 로거를 작성할 필요가 없습니다. 다음 코드에서는 서비스를 등록하지 않아도 되는 기본 로깅을 사용하는 방법을 보여 줍니다.
public class AboutModel : PageModel
{
private readonly ILogger _logger;
public AboutModel(ILogger<AboutModel> logger)
{
_logger = logger;
}
public string Message { get; set; } = string.Empty;
public void OnGet()
{
Message = $"About page visited at {DateTime.UtcNow.ToLongTimeString()}";
_logger.LogInformation(Message);
}
}
위의 코드를 사용하여 프레임워크에서 로깅을 제공하므로 Program.cs
를 업데이트할 필요가 없습니다.
확장 메서드를 사용하여 서비스 그룹 등록
ASP.NET Core 프레임워크에서는 관련 서비스 그룹을 등록하는 규칙을 사용합니다. 규칙은 단일 Add{GROUP_NAME}
확장 메서드를 사용하여 프레임워크 기능에 필요한 모든 서비스를 등록하는 것입니다. 예를 들어 AddControllers 확장 메서드는 MVC 컨트롤러에 필요한 서비스를 등록합니다.
다음 코드는 개별 사용자 계정을 사용하는 Razor Pages 템플릿으로 생성되며 확장 메서드 AddDbContext 및 AddDefaultIdentity를 사용하여 컨테이너에 서비스를 추가하는 방법을 보여 줍니다.
using DependencyInjectionSample.Data;
using Microsoft.AspNetCore.Identity;
using Microsoft.EntityFrameworkCore;
var builder = WebApplication.CreateBuilder(args);
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();
builder.Services.AddDefaultIdentity<IdentityUser>(options => options.SignIn.RequireConfirmedAccount = true)
.AddEntityFrameworkStores<ApplicationDbContext>();
builder.Services.AddRazorPages();
var app = builder.Build();
서비스를 등록하고 옵션을 구성하는 다음 메서드를 고려합니다.
using ConfigSample.Options;
using Microsoft.Extensions.DependencyInjection.ConfigSample.Options;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.Configure<PositionOptions>(
builder.Configuration.GetSection(PositionOptions.Position));
builder.Services.Configure<ColorOptions>(
builder.Configuration.GetSection(ColorOptions.Color));
builder.Services.AddScoped<IMyDependency, MyDependency>();
builder.Services.AddScoped<IMyDependency2, MyDependency2>();
var app = builder.Build();
관련 등록 그룹을 확장 메서드로 이동하여 서비스를 등록할 수 있습니다. 예를 들어, 구성 서비스는 다음 클래스에 추가됩니다.
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;
}
public static IServiceCollection AddMyDependencyGroup(
this IServiceCollection services)
{
services.AddScoped<IMyDependency, MyDependency>();
services.AddScoped<IMyDependency2, MyDependency2>();
return services;
}
}
}
나머지 서비스는 유사한 클래스에 등록됩니다. 다음 코드는 새 확장 메서드를 사용하여 서비스를 등록합니다.
using Microsoft.Extensions.DependencyInjection.ConfigSample.Options;
var builder = WebApplication.CreateBuilder(args);
builder.Services
.AddConfig(builder.Configuration)
.AddMyDependencyGroup();
builder.Services.AddRazorPages();
var app = builder.Build();
참고: 각 services.Add{GROUP_NAME}
확장 메서드는 서비스를 추가하고 잠재적으로 구성합니다. 예를 들어 AddControllersWithViews는 보기에 필요한 서비스 MVC 컨트롤러를 추가하고 AddRazorPages는 Razor Pages에 필요한 서비스를 추가합니다.
서비스 수명
.NET의 종속성 주입의 서비스 수명을 참조하세요.
미들웨어에서 범위 지정 서비스를 사용하려면 다음 방법 중 하나를 사용합니다.
- 미들웨어의
Invoke
또는InvokeAsync
메서드에 서비스를 삽입합니다. 생성자 주입을 사용하면 범위 지정 서비스가 싱글톤처럼 작동하게 하므로 런타임 예외가 throw됩니다. 수명 및 등록 옵션 섹션의 샘플에서는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; }
}
다음 코드는 명명된 수명에 따라 Operation
클래스의 여러 등록을 만듭니다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddTransient<IOperationTransient, Operation>();
builder.Services.AddScoped<IOperationScoped, Operation>();
builder.Services.AddSingleton<IOperationSingleton, Operation>();
var app = builder.Build();
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseMyMiddleware();
app.UseRouting();
app.UseAuthorization();
app.MapRazorPages();
app.Run();
샘플 앱에서는 요청 내의 개체 수명과 요청 간의 개체 수명을 모두 보여 줍니다. 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 IOperationSingleton _singletonOperation;
public MyMiddleware(RequestDelegate next, ILogger<MyMiddleware> logger,
IOperationSingleton singletonOperation)
{
_logger = logger;
_singletonOperation = singletonOperation;
_next = next;
}
public async Task InvokeAsync(HttpContext context,
IOperationTransient transientOperation, 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,
IOperationTransient transientOperation, IOperationScoped scopedOperation)
{
_logger.LogInformation("Transient: " + transientOperation.OperationId);
_logger.LogInformation("Scoped: " + scopedOperation.OperationId);
_logger.LogInformation("Singleton: " + _singletonOperation.OperationId);
await _next(context);
}
로거 출력은 다음을 보여 줍니다.
- Transient 개체는 항상 다릅니다. 임시
OperationId
값은IndexModel
과 미들웨어에서 다릅니다. - Scoped 개체는 제공된 요청에 대해 동일하지만 각각의 새 요청 간에는 다릅니다.
- ‘싱글톤’ 개체는 모든 요청에 동일합니다.
로깅 출력을 줄이려면 appsettings.Development.json
파일에서 "Logging:LogLevel:Microsoft:Error"를 설정합니다.
{
"MyKey": "MyKey from appsettings.Developement.json",
"Logging": {
"LogLevel": {
"Default": "Information",
"System": "Debug",
"Microsoft": "Error"
}
}
}
앱 시작 시 서비스 확인
다음 코드는 앱이 시작될 때 제한된 기간 동안 범위가 지정된 서비스를 확인하는 방법을 보여 줍니다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddScoped<IMyDependency, MyDependency>();
var app = builder.Build();
using (var serviceScope = app.Services.CreateScope())
{
var services = serviceScope.ServiceProvider;
var myDependency = services.GetRequiredService<IMyDependency>();
myDependency.WriteMessage("Call services from main");
}
app.MapGet("/", () => "Hello World!");
app.Run();
범위 유효성 검사
.NET의 종속성 주입의 생성자 주입 동작을 참조하세요.
자세한 내용은 범위 유효성 검사를 참조하세요.
요청 서비스
ASP.NET Core 요청 내의 서비스 및 해당 종속성은 HttpContext.RequestServices을 통해 노출됩니다.
프레임워크는 요청당 범위를 만들고 RequestServices
는 범위가 지정된 서비스 공급자를 공개합니다. 범위가 지정된 모든 서비스는 요청이 활성 상태인 동안 유효합니다.
참고 항목
RequestServices
에서 서비스를 확인하는 것보다 생성자 매개 변수로 종속성을 요청하는 것을 선호합니다. 생성자 매개 변수로 종속성을 요청하면 테스트하기 쉬운 클래스가 생성됩니다.
종속성 주입을 위한 서비스 디자인
종속성 주입을 위한 서비스를 디자인하는 경우
- 상태 저장 정적 클래스 및 멤버를 사용하지 마세요. 대신 싱글톤 서비스를 사용하도록 앱을 설계하여 전역 상태를 만들지 않도록 합니다.
- 서비스 내의 종속 클래스를 직접 인스턴스화하지 마세요. 직접 인스턴스화는 코드를 특정 구현에 결합합니다.
- 서비스를 작고 잘 구성되고 쉽게 테스트할 수 있도록 만듭니다.
클래스에 주입된 종속성이 많은 경우 클래스에 역할이 너무 많고 SRP(단일 책임 원칙)를 위반하는 것일 수 있습니다. 해당 책임 몇 가지를 새로운 클래스로 이동하여 클래스를 리팩터링해 보세요. Razor Pages의 페이지 모델 클래스 및 MVC 컨트롤러 클래스는 UI 고려 사항에 집중해야 합니다.
서비스 삭제
컨테이너는 자신이 만든 IDisposable 형식에 대해 Dispose를 호출합니다. 개발자는 컨테이너에서 확인된 서비스는 삭제해서는 안 됩니다. 형식 또는 팩터리가 싱글톤으로 등록된 경우 컨테이너에서 싱글톤을 자동으로 삭제합니다.
다음 예제에서 서비스는 서비스 컨테이너에 의해 생성되고 자동으로 삭제됩니다. dependency-injection\samples\6.x\DIsample2\DIsample2\Services\Service1.cs
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;
}
}
using DIsample2.Services;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddScoped<Service1>();
builder.Services.AddSingleton<Service2>();
var myKey = builder.Configuration["MyKey"];
builder.Services.AddSingleton<IService3>(sp => new Service3(myKey));
var app = builder.Build();
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, MyKey = MyKey from appsettings.Developement.json
Service1.Dispose
서비스 컨테이너에서 만들지 않은 서비스
다음 코드를 생각해 봅시다.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages();
builder.Services.AddSingleton(new Service1());
builder.Services.AddSingleton(new Service2());
위의 코드에서
- 서비스 인스턴스가 서비스 컨테이너에 의해 만들어지지 않습니다.
- 프레임워크가 서비스를 자동으로 삭제하지 않습니다.
- 개발자가 서비스 삭제를 담당합니다.
임시 및 공유 인스턴스에 대한 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)에 정적으로 액세스하지 마세요.
DI는 정적/전역 개체 액세스 패턴의 ‘대안’입니다. 고정 개체 액세스와 함께 사용할 경우 DI의 장점을 실현할 수 없습니다.
DI의 다중 테넌트에 권장되는 패턴
Orchard Core는 ASP.NET Core에서 모듈식 다중 테넌트 애플리케이션을 빌드하기 위한 애플리케이션 프레임워크입니다. 자세한 내용은 Orchard Core 설명서를 참조하세요.
CMS 고유 기능 없이 Orchard Core Framework를 사용하여 모듈식 다중 테넌트 앱을 빌드하는 방법에 대한 예제는 Orchard Core 샘플을 참조하세요.
프레임워크에서 제공하는 서비스
Program.cs
는 Entity Framework Core, ASP.NET Core MVC 등의 플랫폼 기능을 비롯해 앱이 사용하는 서비스를 등록합니다. 처음에 Program.cs
에 제공되는 IServiceCollection
에는 호스트가 구성된 방법에 따라 달라지는 프레임워크에 의해 정의되는 서비스가 있습니다. ASP.NET Core 템플릿을 기반으로 하는 앱의 경우 프레임워크에서 250개 이상의 서비스를 등록합니다.
다음 표에는 프레임워크에서 등록한 서비스들의 작은 샘플이 나열되어 있습니다.
추가 리소스
- ASP.NET Core의 뷰에 종속성 주입
- ASP.NET Core의 컨트롤러에 종속성 주입
- ASP.NET Core의 요구 사항 처리기에서 종속성 주입
- ASP.NET Core Blazor 종속성 주입
- DI 앱 개발을 위한 NDC 컨퍼런스 패턴
- ASP.NET Core의 앱 시작
- ASP.NET Core의 팩터리 기반 미들웨어 활성화
- IDisposables in ASP.NET Core를 삭제하는 네 가지 방법
- 종속성 주입으로 ASP.NET Core에 정리 코드 작성(MSDN)
- 명시적 종속성 원칙
- Inversion of Control 컨테이너 및 종속성 주입 패턴(Martin Fowler)
- How to register a service with multiple interfaces in ASP.NET Core DI(ASP.NET Core DI의 여러 인터페이스를 사용하여 서비스를 등록하는 방법)
작성자: Kirk Larkin, Steve Smith, Scott Addie 및 Brandon 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 템플릿으로 생성되며 확장 메서드 AddDbContext 및 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
메서드를 고려합니다.
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;
}
public static IServiceCollection AddMyDependencyGroup(
this IServiceCollection services)
{
services.AddScoped<IMyDependency, MyDependency>();
services.AddScoped<IMyDependency2, MyDependency2>();
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 네임스페이스의 확장 메서드 생성에 대한 명명 규칙을 따르는 것이 좋습니다. Microsoft.Extensions.DependencyInjection
네임스페이스에서 확장 메서드를 생성하면 다음을 기대할 수 있습니다.
- 서비스 등록 그룹이 캡슐화됩니다.
- 서비스에 대한 편리한 IntelliSense 액세스가 제공됩니다.
서비스 수명
.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
과 미들웨어에서 다릅니다. - Scoped 개체는 제공된 요청에 대해 동일하지만 각각의 새 요청 간에는 다릅니다.
- ‘싱글톤’ 개체는 모든 요청에 동일합니다.
로깅 출력을 줄이려면 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
에서 서비스를 확인하는 것보다 생성자 매개 변수로 종속성을 요청하는 것을 선호합니다. 생성자 매개 변수로 종속성을 요청하면 테스트하기 쉬운 클래스가 생성됩니다.
종속성 주입을 위한 서비스 디자인
종속성 주입을 위한 서비스를 디자인하는 경우
- 상태 저장 정적 클래스 및 멤버를 사용하지 마세요. 대신 싱글톤 서비스를 사용하도록 앱을 설계하여 전역 상태를 만들지 않도록 합니다.
- 서비스 내의 종속 클래스를 직접 인스턴스화하지 마세요. 직접 인스턴스화는 코드를 특정 구현에 결합합니다.
- 서비스를 작고 잘 구성되고 쉽게 테스트할 수 있도록 만듭니다.
클래스에 주입된 종속성이 많은 경우 클래스에 역할이 너무 많고 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, MyKey = My Key from config
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
를 로드하는 경우를 예로 들 수 있습니다. 다음 방법을 사용하지 마세요.위 이미지에서
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의 장점을 실현할 수 없습니다.
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개 이상의 서비스를 등록합니다.
다음 표에는 프레임워크에서 등록한 서비스들의 작은 샘플이 나열되어 있습니다.
추가 리소스
- ASP.NET Core의 뷰에 종속성 주입
- ASP.NET Core의 컨트롤러에 종속성 주입
- ASP.NET Core의 요구 사항 처리기에서 종속성 주입
- ASP.NET Core Blazor 종속성 주입
- DI 앱 개발을 위한 NDC 컨퍼런스 패턴
- ASP.NET Core의 앱 시작
- ASP.NET Core의 팩터리 기반 미들웨어 활성화
- IDisposables in ASP.NET Core를 삭제하는 네 가지 방법
- 종속성 주입으로 ASP.NET Core에 정리 코드 작성(MSDN)
- 명시적 종속성 원칙
- Inversion of Control 컨테이너 및 종속성 주입 패턴(Martin Fowler)
- How to register a service with multiple interfaces in ASP.NET Core DI(ASP.NET Core DI의 여러 인터페이스를 사용하여 서비스를 등록하는 방법)
ASP.NET Core