.NET 依存関係の挿入

[アーティクル]
03/18/2023

.NET では依存関係の挿入 (DI) ソフトウェア設計パターンがサポートされています。これは、クラスとその依存関係の間で制御の反転 (IoC) を実現するための手法です。 .NET での依存関係の挿入は、構成、ログ、オプションパターンと共に、フレームワークの組み込み部分です。

"依存関係" とは、他のオブジェクトが依存するオブジェクトのことです。他のクラスが依存している、次の Write メソッドを備えた MessageWriter クラスを調べます。

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

クラスは、MessageWriter クラスのインスタンスを作成して、その Write メソッドを使用することができます。次の例で、MessageWriter クラスは Worker クラスの依存関係です。

public class Worker : BackgroundService
{
    private readonly MessageWriter _messageWriter = new MessageWriter();

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _messageWriter.Write($"Worker running at: {DateTimeOffset.Now}");
            await Task.Delay(1000, stoppingToken);
        }
    }
}

このクラスは MessageWriter クラスを作成し、これに直接依存しています。ハードコーディングされた依存関係には、前の例のような問題があり、次の理由から回避する必要があります。

MessageWriter を別の実装で置き換えるには、Worker クラスを変更する必要があります。
MessageWriter が依存関係を含んでいる場合、これらは Worker クラスによって構成する必要があります。複数のクラスが MessageWriter に依存している大規模なプロジェクトでは、構成コードがアプリ全体に分散するようになります。
このような実装では、単体テストを行うことが困難です。アプリはモックまたはスタブの MessageWriter クラスを使用する必要がありますが、この方法では不可能です。

依存関係の挿入は、次の方法によってこれらの問題に対応します。

依存関係の実装を抽象化するための、インターフェイスまたは基底クラスの使用。
サービスコンテナー内の依存関係の登録。 .NET には、組み込みのサービスコンテナー IServiceProvider が用意されています。通常、サービスは、アプリの起動時に登録され、IServiceCollection に追加されます。すべてのサービスが追加されたら、BuildServiceProvider を使用してサービスコンテナーを作成します。
サービスを使用するクラスのコンストラクターへの、サービスの "挿入"。依存関係のインスタンスの作成、およびインスタンスが不要になったときの廃棄の役割を、フレームワークが担当します。

たとえば、IMessageWriter インターフェイスに Write メソッドを定義します。

namespace DependencyInjection.Example;

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

このインターフェイスは、具象型 MessageWriter によって実装されます。

namespace DependencyInjection.Example;

public class MessageWriter : IMessageWriter
{
    public void Write(string message)
    {
        Console.WriteLine($"MessageWriter.Write(message: \"{message}\")");
    }
}

このサンプルコードの場合、具象型 MessageWriter を使用して IMessageWriter サービスが登録されます。 AddScoped メソッドによって、サービスは、1 つの要求の有効期間であるスコープ付き有効期間で登録されます。サービスの有効期間については、この記事の後半で説明します。

using DependencyInjection.Example;

var builder = Host.CreateDefaultBuilder(args);

builder.ConfigureServices(
    services =>
        services.AddHostedService<Worker>()
            .AddScoped<IMessageWriter, MessageWriter>());

using var host = builder.Build();

host.Run();

前のコードでは、サンプルアプリで次の処理が行われます。

ホストビルダーインスタンスを作成します。
次を登録してサービスを構成します。
- ホステッドサービスとしての Worker。詳細については、「.NET の Worker サービス」を参照してください。
- MessageWriter クラスの該当実装があるスコープ付きサービスとしての IMessageWriter インターフェイス。
ホストをビルドして実行します。

ホストには、依存関係挿入サービスプロバイダーが含まれています。また、Worker のインスタンスを自動的に作成し、対応する IMessageWriter 実装を引数として提供するために必要なその他すべての関連サービスが含まれています。

namespace DependencyInjection.Example;

public sealed class Worker : BackgroundService
{
    private readonly IMessageWriter _messageWriter;

    public Worker(IMessageWriter messageWriter) =>
        _messageWriter = messageWriter;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _messageWriter.Write($"Worker running at: {DateTimeOffset.Now}");
            await Task.Delay(1_000, stoppingToken);
        }
    }
}

DI パターンを使用することにより、Worker サービスは次のようになります。

具象型 MessageWriter は使用されず、実装される IMessageWriter インターフェイスのみが使用されます。これにより、Worker サービスが使用する実装は、Worker サービスを変更することなく、簡単に変更できるようになります。
MessageWriter のインスタンスは作成できません。このインスタンスは DI コンテナーによって作成されます。

組み込みのログ API を使用すると、IMessageWriter インターフェイスの実装を向上させることができます。

namespace DependencyInjection.Example;

public class LoggingMessageWriter : IMessageWriter
{
    private readonly ILogger<LoggingMessageWriter> _logger;

    public LoggingMessageWriter(ILogger<LoggingMessageWriter> logger) =>
        _logger = logger;

    public void Write(string message) =>
        _logger.LogInformation("Info: {Msg}", message);
}

更新された ConfigureServices メソッドでは、新しい IMessageWriter の実装が登録されます。

static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureServices((_, services) =>
            services.AddHostedService<Worker>()
                    .AddScoped<IMessageWriter, LoggingMessageWriter>());

メソッドCreateHostBuilderでは、型とを使用しますIHostBuilderHost。これらを使用するには、 Microsoft.Extensions.DependencyInjection と Microsoft.Extensions.Hosting をそれぞれ参照する必要があります。

LoggingMessageWriter は、コンストラクターで要求される ILogger<TCategoryName> によって異なります。 ILogger<TCategoryName> は、フレームワークで提供されるサービスです。

依存関係の挿入をチェーン形式で使用することはよくあります。次に、要求されたそれぞれの依存関係が、それ自身の依存関係を要求します。コンテナーによってグラフ内の依存関係が解決され、完全に解決されたサービスが返されます。解決する必要がある依存関係の集合的なセットは、通常、"依存関係ツリー"、"依存関係グラフ"、または "オブジェクトグラフ" と呼ばれます。

コンテナーでは、(ジェネリック) オープン型を活用し、すべての (ジェネリック) 構築型を登録する必要をなくすことで、ILogger<TCategoryName> を解決します。

依存関係の挿入に関する用語では、サービスは次のようになります。

通常、他のオブジェクト (IMessageWriter サービスなど) にサービスを提供するオブジェクトです。
Web サービスを使用する場合はありますが、サービスは Web サービスに関連付けられていません。

フレームワークは、堅牢なログシステムを備えています。前の例に示されている IMessageWriter の実装は、ログを実装するのではなく、基本的な DI を実演するために記述されています。ほとんどのアプリでは、ロガーを記述する必要はありません。次のコードは、既定のログを使用する方法を示しています。この場合、Worker をホステッドサービス AddHostedService として ConfigureServices に登録するだけで済みます。

public class Worker : BackgroundService
{
    private readonly ILogger<Worker> _logger;

    public Worker(ILogger<Worker> logger) =>
        _logger = logger;

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            _logger.LogInformation("Worker running at: {time}", DateTimeOffset.Now);
            await Task.Delay(1000, stoppingToken);
        }
    }
}

前のコードを使用すると、ログがフレームワークによって提供されるため、ConfigureServices を更新する必要はありません。

複数のコンストラクター検出ルール

型で複数のコンストラクターが定義されている場合、サービスプロバイダーにはどのコンストラクターを使うかを決定するためのロジックがあります。型が DI 解決可能であるパラメーターを一番多く持つコンストラクターが選ばれます。次の C# のサービス例を考えてみます。

public class ExampleService
{
    public ExampleService()
    {
    }

    public ExampleService(ILogger<ExampleService> logger)
    {
        // omitted for brevity
    }

    public ExampleService(FooService fooService, BarService barService)
    {
        // omitted for brevity
    }
}

上記のコードでは、ログ記録が追加されておりサービスプロバイダーから解決可能ですが、FooService 型と BarService 型は解決できないことを想定してください。 ILogger<ExampleService> パラメーターを持つコンストラクターが ExampleService インスタンスを解決するために使われます。より多くのパラメーターが定義されたコンストラクターが存在しますが、FooService 型と BarService 型は DI 解決可能ではありません。

コンストラクターを検出するときにあいまいさがある場合は、例外がスローされます。次の C# のサービス例を考えてみます。

public class ExampleService
{
    public ExampleService()
    {
    }

    public ExampleService(ILogger<ExampleService> logger)
    {
        // omitted for brevity
    }

    public ExampleService(IOptions<ExampleOptions> options)
    {
        // omitted for brevity
    }
}

警告

あいまいな DI 解決可能型パラメーターを持つ ExampleService コードでは、例外がスローされます。これは行わないでください。これは "あいまいな DI 解決可能型" の意味を示すことを目的としたものです。

前の例では、3 つのコンストラクターがあります。最初のコンストラクターにはパラメーターがなく、サービスプロバイダーからのサービスを必要としません。ログ記録とオプションの両方が DI コンテナーに追加されており、DI 解決可能なサービスであることを想定してください。 DI コンテナーによって ExampleService 型の解決が試みられると、2 つのコンストラクターがあいまいであるため、例外がスローされます。

代わりに両方の DI 解決可能な型を受け入れるコンストラクターを定義することで、あいまいさを回避できます。

public class ExampleService
{
    public ExampleService()
    {
    }

    public ExampleService(
        ILogger<ExampleService> logger,
        IOptions<ExampleOptions> options)
    {
        // omitted for brevity
    }
}

拡張メソッドを使用したサービスのグループを登録する

Microsoft 拡張機能には、関連するサービスのグループを登録するための規則が使用されます。規則は、単一の Add{GROUP_NAME} 拡張メソッドを使用して、フレームワーク機能に必要なすべてのサービスを登録するというものです。たとえば、AddOptions 拡張メソッドにより、オプションの使用に必要なすべてのサービスが登録されます。

フレームワークが提供するサービス

ConfigureServices メソッドにより、プラットフォーム機能など、アプリに使用されるサービスが登録されます。最初に、ConfigureServices に提供される IServiceCollection には、フレームワークによって定義されたサービスがあります (ホストの構成方法によって異なります)。 .NET テンプレートに基づくアプリの場合、フレームワークにより、数百単位のサービスが登録されます。

次の表に、フレームワークによって登録されるサービスのごく一部を示します。

サービスの種類	有効期間
Microsoft.Extensions.DependencyInjection.IServiceScopeFactory	シングルトン
IHostApplicationLifetime	シングルトン
Microsoft.Extensions.Logging.ILogger<TCategoryName>	シングルトン
Microsoft.Extensions.Logging.ILoggerFactory	シングルトン
Microsoft.Extensions.ObjectPool.ObjectPoolProvider	シングルトン
Microsoft.Extensions.Options.IConfigureOptions<TOptions>	一時的
Microsoft.Extensions.Options.IOptions<TOptions>	シングルトン
System.Diagnostics.DiagnosticListener	シングルトン
System.Diagnostics.DiagnosticSource	シングルトン

サービスの有効期間

サービスは、次のいずれかの有効期間で構成できます。

一時的
スコープ
シングルトン

次のセクションでは、前の有効期間について個別に説明します。登録される各サービスの適切な有効期間を選択します。

一時的

有効期間が一時的なサービスは、サービスコンテナーから要求されるたびに作成されます。この有効期間は、軽量でステートレスのサービスに最適です。 AddTransient で一時的なサービスを登録します。

要求を処理するアプリでは、一時的なサービスが要求の最後に破棄されます。

スコープ

Web アプリケーションの場合、スコープ付き有効期間は、クライアント要求 (接続) ごとにサービスが 1 回作成されることを示します。 AddScoped でスコープ付きサービスを登録します。

要求を処理するアプリでは、スコープ付きサービスは要求の最後で破棄されます。

Entity Framework Core を使用する場合、既定では AddDbContext 拡張メソッドによって、スコープ付き有効期間を持つ DbContext 型が登録されます。

注意

シングルトンからスコープ付きサービスを解決 "しないで" ください。また、たとえば一時的なサービスにより、間接的に解決しないようにご注意ください。後続の要求を処理する際に、サービスが正しくない状態になる可能性があります。次の場合は問題ありません。

スコープ付きまたは一時的なサービスからシングルトンサービスを解決する。
スコープ付きサービスを、別のスコープ付きまたは一時的なサービスから解決する。

既定では、開発環境で、より長い有効期間を持つ別のサービスからサービスを解決すると、例外がスローされます。詳しくは、「スコープの検証」をご覧ください。

シングルトン

シングルトン有効期間サービスが作成されるのは、次のいずれかの場合です。

それらが初めて要求された場合。
開発者によって、実装インスタンスがコンテナーに直接提供される場合。このアプローチはほとんど必要ありません。

依存関係の挿入コンテナーから送信されるサービス実装の後続の要求すべてには、同じインスタンスが使用されます。アプリをシングルトンで動作させる必要がある場合は、サービスコンテナーによるサービスの有効期間の管理を許可してください。シングルトンデザインパターンを実装したり、シングルトンを破棄するコードを提供したりしないでください。コンテナーからサービスを解決したコードによって、サービスが破棄されることはありません。型またはファクトリがシングルトンとして登録されている場合、コンテナーによってシングルトンが自動的に破棄されます。

シングルトンサービスを AddSingleton で登録します。シングルトンサービスはスレッドセーフである必要があり、ほとんどの場合、ステートレスサービスで使用されます。

要求を処理するアプリでは、アプリのシャットダウン時に ServiceProvider が破棄されるとき、シングルトンサービスが破棄されます。アプリがシャットダウンされるまでメモリは解放されないため、シングルトンサービスでのメモリ使用を考慮してください。

サービス登録メソッド

このフレームワークでは、特定のシナリオで役立つサービス登録拡張メソッドが提供されます。

メソッド	自動 object 破棄	複数実装	引数を渡す
`Add{LIFETIME}<{SERVICE}, {IMPLEMENTATION}>()` 例: `services.AddSingleton<IMyDep, MyDep>();`	はい	はい	いいえ
`Add{LIFETIME}<{SERVICE}>(sp => new {IMPLEMENTATION})` 次に例を示します。 `services.AddSingleton<IMyDep>(sp => new MyDep());` `services.AddSingleton<IMyDep>(sp => new MyDep(99));`	はい	はい	はい
`Add{LIFETIME}<{IMPLEMENTATION}>()` 例: `services.AddSingleton<MyDep>();`	はい	いいえ	いいえ
`AddSingleton<{SERVICE}>(new {IMPLEMENTATION})` 次に例を示します。 `services.AddSingleton<IMyDep>(new MyDep());` `services.AddSingleton<IMyDep>(new MyDep(99));`	いいえ	はい	はい
`AddSingleton(new {IMPLEMENTATION})` 次に例を示します。 `services.AddSingleton(new MyDep());` `services.AddSingleton(new MyDep(99));`	いいえ	いいえ	はい

型の廃棄の詳細については、「サービスの破棄」を参照してください。

実装型のみでサービスを登録することは、同じ実装とサービスの型でそのサービスを登録することと同じです。明示的なサービス型を使用しないメソッドを使用してサービスの複数の実装を登録できないのは、このためです。これらのメソッドでは、サービスの複数の "インスタンス" を登録できますが、すべて同じ "実装" 型になります。

上記のサービス登録メソッドのずれかを使用して、同じサービス型の複数のサービスインスタンスを登録できます。次の例では、IMessageWriter をサービス型として使用して、AddSingleton を 2 回呼び出します。 2 回目の AddSingleton の呼び出しにより、IMessageWriter として解決された場合は前のものがオーバーライドされ、IEnumerable<IMessageWriter> を介して複数のサービスが解決された場合は前のものに追加されます。 IEnumerable<{SERVICE}> を介して解決された場合、サービスは登録された順に表示されます。

using ConsoleDI.IEnumerableExample;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;

using IHost host = CreateHostBuilder(args).Build();

_ = host.Services.GetService<ExampleService>();

await host.RunAsync();

static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        .ConfigureServices((_, services) =>
            services.AddSingleton<IMessageWriter, ConsoleMessageWriter>()
                    .AddSingleton<IMessageWriter, LoggingMessageWriter>()
                    .AddSingleton<ExampleService>());

上記のサンプルソースコードを使用すると、IMessageWriter の 2 つの実装が登録されます。

using System.Diagnostics;

namespace ConsoleDI.IEnumerableExample;

public sealed class ExampleService
{
    public ExampleService(
        IMessageWriter messageWriter,
        IEnumerable<IMessageWriter> messageWriters)
    {
        Trace.Assert(messageWriter is LoggingMessageWriter);

        var dependencyArray = messageWriters.ToArray();
        Trace.Assert(dependencyArray[0] is ConsoleMessageWriter);
        Trace.Assert(dependencyArray[1] is LoggingMessageWriter);
    }
}

ExampleService により、2 つのコンストラクターパラメーター (1 つの IMessageWriter と IEnumerable<IMessageWriter>) が定義されます。 1 つの IMessageWriter は登録された最後の実装です。一方、IEnumerable<IMessageWriter> は登録されたすべての実装を表します。

フレームワークには TryAdd{LIFETIME} 拡張メソッドも用意されており、実装がまだ登録されていない場合にのみ、サービスが登録されます。

次の例では、AddSingleton の呼び出しによって、IMessageWriter の実装として ConsoleMessageWriter が登録されます。 TryAddSingleton の呼び出しでは何も行われません。IMessageWriter には登録された実装が既に含まれているからです。

services.AddSingleton<IMessageWriter, ConsoleMessageWriter>();
services.TryAddSingleton<IMessageWriter, LoggingMessageWriter>();

TryAddSingleton は、既に追加されており、"試行" は失敗するため、効果はありません。 ExampleService により、以下がアサートされます。

public class ExampleService
{
    public ExampleService(
        IMessageWriter messageWriter,
        IEnumerable<IMessageWriter> messageWriters)
    {
        Trace.Assert(messageWriter is ConsoleMessageWriter);
        Trace.Assert(messageWriters.Single() is ConsoleMessageWriter);
    }
}

詳細については、次を参照してください。

TryAddEnumerable(ServiceDescriptor) メソッドでは、"同じ型" の実装がまだ存在しない場合にのみサービスが登録されます。複数のサービスは、IEnumerable<{SERVICE}> によって解決されます。サービスを登録するときに、同じ型のいずれかがまだ追加されていない場合は、インスタンスを追加します。ライブラリの作成者は、コンテナー内の実装の複数のコピーを登録しないようにするため TryAddEnumerable を使用します。

次の例では、TryAddEnumerable の最初の呼び出しで、IMessageWriter1 の実装として MessageWriter が登録されます。 2 番目の呼び出しでは IMessageWriter2 に MessageWriter が登録されます。 3 番目の呼び出しでは何も行われません。IMessageWriter1 には MessageWriter の登録済みの実装が既に含まれているからです。

public interface IMessageWriter1 { }
public interface IMessageWriter2 { }

public class MessageWriter : IMessageWriter1, IMessageWriter2
{
}

services.TryAddEnumerable(ServiceDescriptor.Singleton<IMessageWriter1, MessageWriter>());
services.TryAddEnumerable(ServiceDescriptor.Singleton<IMessageWriter2, MessageWriter>());
services.TryAddEnumerable(ServiceDescriptor.Singleton<IMessageWriter1, MessageWriter>());

サービスの登録は、通常、同じ種類の複数の実装を登録する場合を除き、順序に依存しません。

IServiceCollection は ServiceDescriptor オブジェクトのコレクションです。次の例は、ServiceDescriptor の作成と追加によってサービスを登録する方法を示しています。

string secretKey = Configuration["SecretKey"];
var descriptor = new ServiceDescriptor(
    typeof(IMessageWriter),
    _ => new DefaultMessageWriter(secretKey),
    ServiceLifetime.Transient);

services.Add(descriptor);

組み込みの Add{LIFETIME} メソッドでも同じ方法が使用されます。たとえば、AddScoped のソースコードをご覧ください。

コンストラクターの挿入の動作

サービスは次を使用することによって解決できます。

IServiceProvider
ActivatorUtilities:
- コンテナーに登録されていないオブジェクトが作成されます。
- 一部のフレームワーク機能に使用されます。

コンストラクターは、依存関係の挿入によって提供されない引数を受け取ることができますが、引数は既定値を割り当てる必要があります。

IServiceProvider または ActivatorUtilities によってサービスを解決する場合、コンストラクターの挿入には、"パブリック" コンストラクターが必要です。

ActivatorUtilities によってサービスを解決する場合、コンストラクターの挿入に必要なことは、該当するコンストラクターが 1 つだけ存在することです。コンストラクターのオーバーロードはサポートされていますが、依存関係の挿入によってすべての引数を設定できるオーバーロードは 1 つしか存在できません。

スコープの検証

アプリが Development 環境で実行されていて、ホストを構築するために CreateDefaultBuilder が呼び出される場合、既定のサービスプロバイダーによって次を確認するためのチェックが実行されます。

スコープ付きサービスが、ルートサービスプロバイダーによって解決されない。
スコープ付きサービスが、シングルトンに挿入されない。

BuildServiceProvider が呼び出されると、ルートサービスプロバイダーが作成されます。ルートサービスプロバイダーの有効期間は、プロバイダーがアプリで開始されるとアプリの有効期間に対応し、アプリのシャットダウン時には破棄されます。

スコープサービスは、それを作成したコンテナーによって破棄されます。ルートコンテナーに作成されたスコープ付きサービスは、アプリのシャットダウン時に、ルートコンテナーによってのみ破棄されるため、サービスの有効期間は実質的にシングルトンに昇格されます。 BuildServiceProvider が呼び出されると、サービススコープの検証がこれらの状況をキャッチします。

スコープのシナリオ

IServiceScopeFactory は常にシングルトンとして登録されますが、IServiceProvider は包含クラスの有効期間に基づいて変化する可能性があります。たとえば、スコープからサービスを解決し、それらのサービスのいずれかが IServiceProvider 受け取ると、それは、スコープ付のインスタンスになります。

BackgroundService などの IHostedService の実装内でスコープサービスを実現するには、コンストラクターインジェクションを介してサービスの依存関係を挿入 "しないでください"。代わりに、IServiceScopeFactory を挿入し、スコープを作成し、そしてそのスコープから依存関係を解決して適切なサービス有効期間を使用します。

namespace WorkerScope.Example;

public sealed class Worker : BackgroundService
{
    private readonly ILogger<Worker> _logger;
    private readonly IServiceScopeFactory _serviceScopeFactory;

    public Worker(ILogger<Worker> logger, IServiceScopeFactory serviceScopeFactory) =>
        (_logger, _serviceScopeFactory) = (logger, serviceScopeFactory);

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            using (IServiceScope scope = _serviceScopeFactory.CreateScope())
            {
                try
                {
                    _logger.LogInformation(
                        "Starting scoped work, provider hash: {hash}.",
                        scope.ServiceProvider.GetHashCode());

                    var store = scope.ServiceProvider.GetRequiredService<IObjectStore>();
                    var next = await store.GetNextAsync();
                    _logger.LogInformation("{next}", next);

                    var processor = scope.ServiceProvider.GetRequiredService<IObjectProcessor>();
                    await processor.ProcessAsync(next);
                    _logger.LogInformation("Processing {name}.", next.Name);

                    var relay = scope.ServiceProvider.GetRequiredService<IObjectRelay>();
                    await relay.RelayAsync(next);
                    _logger.LogInformation("Processed results have been relayed.");

                    var marked = await store.MarkAsync(next);
                    _logger.LogInformation("Marked as processed: {next}", marked);
                }
                finally
                {
                    _logger.LogInformation(
                        "Finished scoped work, provider hash: {hash}.{nl}",
                        scope.ServiceProvider.GetHashCode(), Environment.NewLine);
                }
            }
        }
    }
}

前のコードでは、アプリが実行されている間、バックグラウンドサービスは次のようになります。

IServiceScopeFactory に依存する。
追加のサービスを解決するために IServiceScope を作成する。
利用に向けてスコープ付のサービスを解決する。
オブジェクトを処理してから、それらを中継し、最後に処理済みとしてマークする。

サンプルソースコードから、スコープ付きサービスの有効期間が IHostedService の実装にどのような恩恵をもたらすかを確認できます。