Blazor의 DI Scape 정보

이 글에서 Blazor에서 DI의 각 Scape에 대해 Blazor Server, Blazor Web Assiembly의 다른 관점으로 보고 싶습니다.

디가 뭐예요?

DI는 Dependency Injection의 약자로 의존성 주입으로 번역됩니다.유형을 희소한 결합으로 만들고 유연한 소프트웨어 개발을 가능하게 한다.
예를 들어 제3자의 프로그램 라이브러리가 메일을 보내는 데 사용된다고 가정한다.일반적으로 이 라이브러리를 사용하려면 라이브러리 클래스 실례를 만듭니다.이렇게 하면 라이브러리 클래스와 사용할 클래스가 밀접하게 결합된다.
DI는 인터페이스를 통해 클래스 실례를 가져와 클래스 간의 희소한 결합을 할 수 있다.
DI에 대한 자세한 내용은 여기서 설명하지 않고 다른 글과 책 등을 참조하시기 바랍니다.

DI의 스코프는?

DI는 클래스 실례를 유연하게 생성할 수 있지만, 실례를 생성할 때 색인의 유효한 범위를 확정할 수 있습니다.이 인스턴스의 유효 범위는 Scape입니다.ASP.NET Core Blazer 표준 DI를 사용할 경우 Transient, Scped, Singleton 세 범위에서 인스턴스를 관리할 수 있습니다.각각의 기본적인 범위는 다음과 같지만, Blazor Server인지 Blazor WebAssiembly인지 동작에 따라 차이가 있다.
구역
설명
Transient
어셈블리에 액세스할 때마다 인스턴스가 생성됩니다.
Scoped
인스턴스를 사용자 단위로 생성합니다.각 구성 요소 간에 공통된 실례를 사용합니다.
Singleton
전체 응용 프로그램에서 실례를 생성합니다.따라서 사용자마다 실례를 공유한다.
트랜시언트의 동작과 관련해서는 블라조어 서버, 블라조어 웹애시엠블리는 다르지 않지만, 스쿠퍼드, 싱레톤의 동작에 차이가 있어 각각 해설하고 싶다.

Blazor Server의 각 Scope 작업 정보

Blazor Server에서 각 Scope의 동작을 확인하고 싶습니다.우선, 표준으로 생성된 Counter 구성 요소 수를 보존하는 서비스를 만듭니다.
CounterService.cs

public class CounterService
{
    public int Value { get; set; }

    public void Increment()
    {
        Value++;
    }
}

Transient의 경우

Program.cs에서 만든 CounterSerive입니다.DI 컨테이너에 cs를 등록합니다.
(NET5까지인 경우 Startup.cs의public void Configure Services(Iservice Collection services)에 등록하십시오.)
Program.cs

builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();
builder.Services.AddTransient<CounterService>(); //追加

var app = builder.Build();

Counter.라조 수정.
Counter.razor

@page "/counter"
@inject CounterService CounterService

<PageTitle>Counter</PageTitle>

<h1>Counter</h1>

<p role="status">Current count: @CounterService.Value</p>

<button class="btn btn-primary" @onclick="CounterService.Increment">Click me</button>

@code {
}

동작을 확인하다.구성 요소 전환 표시는 실례를 초기화하고 계수는 0을 되돌려줍니다.

Scoped의 경우

이번에는 CounterSerive입니다.Scoped를 사용하여 DI 컨테이너에 cs를 등록합니다.
Program.cs

builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();
builder.Services.AddScoped<CounterService>(); //追加

var app = builder.Build();

구성 요소를 전환하더라도 카운터 수는 유지됩니다.하지만 재부팅 후 계수가 초기화됩니다.

Singleton 시

마지막으로, CounterSerive.Singleton을 사용하여 DI 컨테이너에 cs를 등록합니다.
Program.cs

builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();
builder.Services.AddSingleton<CounterService>(); //追加

var app = builder.Build();

구성 요소를 전환하더라도 카운터 수는 유지되며 다른 브라우저(다른 사용자)에 표시되어도 동일한 수가 표시됩니다.다시 로드할 때 0을 반환하지 않고 최신 카운트를 표시합니다.

Blazor Server의 DI Scape 요약

Blazor Server는 이름과 같이 서버 측에서 실행되기 때문에 Sigleton은 동일한 프로세스 내에서 인스턴스를 공유합니다.따라서 여러 브라우저 또는 여러 사용자가 액세스할 때 동일한 인스턴스가 사용됩니다.Scoped의 경우 각 클라이언트와 서버 간의 SignalR 연결에 인스턴스가 생성됩니다.따라서 연결이 유효하기만 하면 같은 실례를 사용할 수 있다.브라우저를 다시 불러오면 다시 연결되어 새로운 실례가 생성됩니다.
그림에서 보여준 내용은 다음과 같다.

Blazor WebAssiembly의 각 Scope 작업 정보

다음으로 Blazor WebAssiembly의 각 Scope 동작을 확인하고 싶습니다.또한 예약된 Counter 구성 요소 수를 사용하는 서비스도 있습니다.

Transient의 경우

동작을 확인하다.Blazor Server와 마찬가지로 구성 요소 표시를 전환하면 인스턴스가 초기화되고 카운트가 0으로 반환됩니다.

Scped, Singleton의 경우

Blazor WebAssembly의 경우 Scoped와 Singleton의 동작이 같다.이것은 모든 브라우저 탭이 WebAssiembly의 프로세스를 실행하기 때문에 Singleton의 프로세스 유효 범위는 Scped의 범위와 같습니다.따라서 Singleton의 경우에도 다시 로드하면 인스턴스가 다시 생성됩니다.옵션이 다르면 다른 과정이 되기 때문에 다른 실례가 된다.

Blazor WebAssiembly의 DI Scape 요약

블라조 웹애슬럼블리에서 각 태그는 고유의 과정이기 때문에 스프레드, 싱레톤도 같은 동작을 한다.
브라우저의 모든 탭은 독립된 프로그램 프로세스로 공통된 상태를 공유하지 않습니다.
그림에서 보여준 내용은 다음과 같다.

총결산

Blazor Server, Blazor WebAssiembly에서는 각 프로세스의 실행 환경이 다릅니다.각 환경의 특징을 이해하고 DI를 효과적으로 활용했으면 좋겠다고 생각한다.