【C#】依存性注入（DI）完全ガイド｜ライフタイム・Keyed Services・Decorator・HostedService・落とし穴まで

// Before: NotificationService が SmtpMessageSender を直接 new している
public class NotificationService_Bad
{
    private readonly SmtpMessageSender _sender = new();   // 具象依存

    public Task NotifyAsync(string userId, string message)
        => _sender.SendAsync($"{userId}@example.com", message);
}
// 問題:
//  1. SmtpMessageSender を差し替えられない（SMS や別プロバイダに対応できない）
//  2. テストで本物のSMTPが呼ばれてしまう
//  3. SmtpMessageSender の設定・ライフタイムをこの型が知っている必要がある

// After: インターフェースを受け取る（依存性逆転）
public interface IMessageSender
{
    Task SendAsync(string to, string body);
}

public sealed class NotificationService
{
    private readonly IMessageSender _sender;

    public NotificationService(IMessageSender sender) => _sender = sender;

    public Task NotifyAsync(string userId, string message)
        => _sender.SendAsync($"{userId}@example.com", message);
}
// 効果:
//  1. 実装を差し替え可能（SMTP/SendGrid/ダミー）
//  2. テストでフェイク実装を注入できる
//  3. NotificationService は「誰を使うか」を知らなくてよい

// ① コンストラクタ注入（推奨）
public sealed class OrderService
{
    private readonly IOrderRepository _repo;
    private readonly IPaymentGateway  _payment;
    public OrderService(IOrderRepository repo, IPaymentGateway payment)
        => (_repo, _payment) = (repo, payment);
}

// C# 12+ の Primary Constructor ならフィールド宣言を省ける
public sealed class OrderService2(IOrderRepository repo, IPaymentGateway payment)
{
    public Task ProcessAsync() => repo.SaveAsync();
}

// ② プロパティ注入（MS.DI 標準外 / オプション依存）
public sealed class AuditableService
{
    public ILogger Logger { get; set; } = NullLogger.Instance; // デフォルト値
}

// ③ メソッド注入（ASP.NET Core の [FromServices]）
app.MapGet("/users/{id}", (int id, [FromServices] IUserService svc) =>
    svc.GetAsync(id));

using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();

// Singleton: 1 インスタンスで複数スレッドから共有される
// → 必ずスレッドセーフに実装する
services.AddSingleton<IConfiguration, FrozenConfiguration>();
services.AddSingleton<IHttpClientFactory, DefaultHttpClientFactory>();
services.AddSingleton<IMemoryCache, MemoryCache>();

// Scoped: HTTP リクエスト（または using var scope = ...Scope()）の中で同じインスタンス
// → DbContext は典型的な Scoped（リクエスト内でユニットオブワーク）
services.AddScoped<ApplicationDbContext>();
services.AddScoped<IUserService, UserService>();

// Transient: 解決のたびに新しいインスタンス
// → 軽量で状態を持たないバリデーターやメッセージビルダーに
services.AddTransient<IMessageFormatter, JsonMessageFormatter>();
services.AddTransient<IOrderValidator, OrderValidator>();

var provider = services.BuildServiceProvider();

// NG: Singleton が Scoped な DbContext をコンストラクタで受ける
public class SingletonCache
{
    private readonly AppDbContext _db; // Scoped!
    public SingletonCache(AppDbContext db) => _db = db; // ⚠ 危険
}
// → アプリ起動時に1回だけ解決される DbContext を永遠に使い続ける
//    接続プールが枯渇したり、リクエスト間で状態が混ざる

// OK: Singleton から Scoped が必要なら IServiceScopeFactory でスコープを作る
public class SingletonJob
{
    private readonly IServiceScopeFactory _scopeFactory;
    public SingletonJob(IServiceScopeFactory scopeFactory)
        => _scopeFactory = scopeFactory;

    public async Task RunAsync()
    {
        using var scope = _scopeFactory.CreateScope();
        var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
        await db.SaveChangesAsync();
    } // ← using の終わりで Scoped が解放される
}

// 起動時検証で Captured Dependencies を自動検出
var host = Host.CreateDefaultBuilder()
    .UseDefaultServiceProvider(opt =>
    {
        opt.ValidateOnBuild = true;   // 起動時に全サービスの解決を検証
        opt.ValidateScopes  = true;   // Scoped をルートから解決すると例外
    })
    .ConfigureServices(s => { /* ... */ })
    .Build();

// .NET 8 以降: 同じインターフェースを「キー」で区別して複数登録できる
var services = new ServiceCollection();

services.AddKeyedSingleton<IMessageSender, SmtpSender>("smtp");
services.AddKeyedSingleton<IMessageSender, SlackSender>("slack");
services.AddKeyedSingleton<IMessageSender, TwilioSender>("sms");

// コンストラクタで [FromKeyedServices] で取得
public sealed class OrderNotifier(
    [FromKeyedServices("smtp")]  IMessageSender email,
    [FromKeyedServices("slack")] IMessageSender slack)
{
    public async Task NotifyAsync(Order o)
    {
        await email.SendAsync(o.CustomerEmail, "ご注文ありがとうございます");
        await slack.SendAsync("#sales", $"新規注文: {o.Id}");
    }
}

// 解決側: GetRequiredKeyedService<T>
var provider = services.BuildServiceProvider();
var sms = provider.GetRequiredKeyedService<IMessageSender>("sms");

// キーに enum や任意のオブジェクトも使える
public enum Channel { Email, Slack, Sms }
services.AddKeyedSingleton<IMessageSender, SmtpSender>(Channel.Email);

// 同じ型に複数登録すると、IEnumerable<T> で全部取得できる
services.AddSingleton<IValidator, RequiredValidator>();
services.AddSingleton<IValidator, RangeValidator>();
services.AddSingleton<IValidator, EmailValidator>();

public sealed class CompositeValidator(IEnumerable<IValidator> validators)
{
    public ValidationResult Validate(object o) =>
        validators.Select(v => v.Validate(o)).Aggregate(ValidationResult.Merge);
}

// TryAdd* 系: 既に登録済みなら追加しない（冪等登録）
services.TryAddSingleton<ILogger, ConsoleLogger>();     // 1回目: 追加される
services.TryAddSingleton<ILogger, FileLogger>();        // 2回目: 無視される
// → ライブラリで「デフォルト実装を用意するが、ユーザーが上書き済みなら尊重」に便利

// TryAddEnumerable: 同じ型でも実装クラスが重複する登録のみ避ける
services.TryAddEnumerable(ServiceDescriptor.Singleton<IValidator, EmailValidator>());
services.TryAddEnumerable(ServiceDescriptor.Singleton<IValidator, EmailValidator>());
// → 2回目は「同じ実装クラス」なのでスキップ

// ① 既存インスタンスをそのまま登録
var cfg = new FrozenConfig("production");
services.AddSingleton<IConfiguration>(cfg);  // インスタンス登録はライフタイムが無意味化する

// ② ファクトリーデリゲート（解決時の sp で他サービスを引き出せる）
services.AddScoped<IDatabaseClient>(sp =>
{
    var opt = sp.GetRequiredService<IOptions<DbOptions>>().Value;
    var log = sp.GetRequiredService<ILogger<DatabaseClient>>();
    return new DatabaseClient(opt.ConnectionString, log);
});

// ③ Open Generics（ジェネリック型の型引数ごとに登録される）
services.AddSingleton(typeof(IRepository<>), typeof(EfRepository<>));
// → IRepository<User>, IRepository<Order> などで EfRepository<User>/EfRepository<Order> が解決される

// ④ 条件付きファクトリー（環境によって実装を切り替え）
services.AddSingleton<IMessageSender>(sp =>
{
    var env = sp.GetRequiredService<IHostEnvironment>();
    return env.IsDevelopment()
        ? new ConsoleSender()                     // 開発ではコンソール出力
        : new SmtpSender(sp.GetRequiredService<IOptions<SmtpOptions>>());
});

// 同じインターフェースを「元の実装」と「装飾した実装」で2段登録する
// Scrutor ライブラリを使うと AddScoped<T, TDecorator>().Decorate<T>() が使えるが
// MS.DI 標準でも手動で実装できる

public interface IUserRepository { Task<User?> GetAsync(int id); }

public sealed class DbUserRepository : IUserRepository { /* 省略 */ }

// キャッシング Decorator
public sealed class CachingUserRepository : IUserRepository
{
    private readonly IUserRepository _inner;
    private readonly IMemoryCache    _cache;

    public CachingUserRepository(IUserRepository inner, IMemoryCache cache)
        => (_inner, _cache) = (inner, cache);

    public async Task<User?> GetAsync(int id)
    {
        if (_cache.TryGetValue(id, out User? u)) return u;
        u = await _inner.GetAsync(id);
        if (u != null) _cache.Set(id, u, TimeSpan.FromMinutes(5));
        return u;
    }
}

// 登録: Decorator が外側、内部実装を DI で解決してもらう
services.AddSingleton<DbUserRepository>();
services.AddSingleton<IUserRepository>(sp =>
    new CachingUserRepository(
        sp.GetRequiredService<DbUserRepository>(),
        sp.GetRequiredService<IMemoryCache>()));

// 使用側から見ると IUserRepository だが、実体は CachingUserRepository → DbUserRepository

public sealed class SmtpOptions
{
    public required string Host { get; init; }
    public int Port { get; init; } = 587;
}

// 登録
builder.Services.Configure<SmtpOptions>(builder.Configuration.GetSection("Smtp"));

// ① IOptions<T>: 起動時の設定値（変わらない）
public sealed class MailService(IOptions<SmtpOptions> opt)
{
    private readonly SmtpOptions _o = opt.Value;
}

// ② IOptionsSnapshot<T>: リクエストごとに最新を取得（Scoped）
public sealed class ApiController(IOptionsSnapshot<SmtpOptions> opt) : ControllerBase
{
    public IActionResult Get() => Ok(opt.Value.Host);
    // → appsettings.json を編集して保存すると次リクエストから反映される
}

// ③ IOptionsMonitor<T>: Singleton でも変更を購読できる
public sealed class ConnectionPool(IOptionsMonitor<SmtpOptions> monitor)
{
    public ConnectionPool(IOptionsMonitor<SmtpOptions> monitor)
    {
        // 現在値
        var current = monitor.CurrentValue;

        // 変更通知を購読（HostedService に向いている）
        monitor.OnChange(newOpts =>
        {
            Console.WriteLine($"設定が変更されました: {newOpts.Host}");
        });
    }
}

using Microsoft.Extensions.Hosting;

public sealed class CleanupWorker(
    IServiceScopeFactory scopeFactory,
    ILogger<CleanupWorker> logger)
    : BackgroundService
{
    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        while (!stoppingToken.IsCancellationRequested)
        {
            try
            {
                // Scoped 依存は必ず自前でスコープを作って取得する
                using var scope = scopeFactory.CreateScope();
                var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
                await db.Sessions
                    .Where(s => s.ExpiresAt < DateTime.UtcNow)
                    .ExecuteDeleteAsync(stoppingToken);
            }
            catch (Exception ex)
            {
                logger.LogError(ex, "Cleanup failed");
            }
            await Task.Delay(TimeSpan.FromMinutes(10), stoppingToken);
        }
    }
}

// 登録: AddHostedService で Singleton として登録される
builder.Services.AddHostedService<CleanupWorker>();

// NG: HttpClient を普通に new するとソケット枯渇・DNS 変更の反映遅れ
public sealed class BadApiClient
{
    public async Task GetAsync() =>
        await new HttpClient().GetAsync("https://api.example.com");  // アンチパターン
}

// OK: Typed HttpClient で登録すると IHttpClientFactory が裏で管理してくれる
public sealed class PaymentApiClient
{
    private readonly HttpClient _http;

    public PaymentApiClient(HttpClient http)
    {
        _http = http;
        _http.BaseAddress = new Uri("https://api.payment.example.com");
    }

    public Task<HttpResponseMessage> ChargeAsync(decimal amount) =>
        _http.PostAsJsonAsync("/charge", new { Amount = amount });
}

// 登録
builder.Services.AddHttpClient<PaymentApiClient>();

// Polly を組み合わせてリトライ・サーキットブレイカーも追加可能
builder.Services.AddHttpClient<PaymentApiClient>()
    .AddStandardResilienceHandler(); // .NET 8+ の標準レジリエンス

// 使用側
public class OrderService(PaymentApiClient payment)
{
    public Task ChargeAsync(Order o) => payment.ChargeAsync(o.Total);
}

// NG: IServiceProvider を直接注入して Get で解決する
public class OrderService
{
    private readonly IServiceProvider _sp;
    public OrderService(IServiceProvider sp) => _sp = sp;

    public Task ProcessAsync()
    {
        var repo = _sp.GetRequiredService<IOrderRepository>();  // 必要になった時に解決
        return repo.SaveAsync();
    }
}
// 問題:
//  - 依存関係がシグネチャに現れない（何を使うか外から分からない）
//  - テストで何をモックすべきか不明
//  - ValidateOnBuild で検出できない

// OK: 必要な依存はコンストラクタで明示する
public class OrderServiceGood(IOrderRepository repo)
{
    public Task ProcessAsync() => repo.SaveAsync();
}

// 循環依存: A が B を、B が A を要求する
public class A { public A(B b) { } }
public class B { public B(A a) { } }

services.AddSingleton<A>();
services.AddSingleton<B>();
provider.GetRequiredService<A>(); // InvalidOperationException: A circular dependency was detected

// 対処① — 責務を分割して共通部分を切り出す
//    A, B が共通の処理 X に依存するなら、X を別クラスにする

// 対処② — イベントで結合を緩める
//    A が B を直接参照するのではなく、「何かが起きた」イベントを発行し、
//    B はそれを購読する（Mediator / MediatR パターン）

// 対処③ — どうしても必要なら Lazy<T> や遅延注入
public class A(Lazy<B> b) // B は最初のアクセス時に初めて解決される
{
    public void DoSomething() => b.Value.Do();
}

using var scope = provider.CreateScope();
var sp = scope.ServiceProvider;

// GetService: 未登録なら null を返す（C# 8 nullable 警告で検出できる）
IOrderRepository? maybeRepo = sp.GetService<IOrderRepository>();
if (maybeRepo is null)  // ← これを忘れると NullReferenceException

// GetRequiredService: 未登録なら InvalidOperationException を投げる（推奨）
IOrderRepository repo = sp.GetRequiredService<IOrderRepository>();

// 登録されている前提のコードでは GetRequiredService を使うほうが安全
// 登録されているか分からない状況（プラグインシステム等）では GetService

// MS.DI は「コンテナが生成したインスタンス」だけを自動 Dispose する
public class DbConn : IDisposable { /* ... */ }

// ① 登録: コンテナ管理 → スコープ終了時に自動 Dispose
services.AddScoped<DbConn>();

// ② インスタンス登録: コンテナは Dispose を呼ばない（呼び出し側の責任）
var conn = new DbConn();
services.AddSingleton(conn);
// → provider.Dispose() しても conn.Dispose() は呼ばれない
// → ownsInstance パラメータ指定なしの AddSingleton(instance) は要注意

// ③ ファクトリー登録: 戻り値はコンテナ管理対象として Dispose される
services.AddScoped<DbConn>(sp => new DbConn("conn-string")); // これは自動 Dispose される