Wstrzykiwanie zależności w ASP.NET Core

Przez Kirk Larkin, Steve Smith i Brandon Dahler

ASP.NET Core obsługuje wzorzec projektowania oprogramowania iniekcji zależności (DI), który jest techniką osiągnięcia inwersji kontroli (IoC) między klasami i ich zależnościami.

Aby uzyskać więcej informacji specyficznych dla wstrzykiwania zależności w kontrolerach MVC, zobacz Wstrzykiwanie zależności do kontrolerów w ASP.NET Core.

Aby uzyskać informacje na temat używania wstrzykiwania zależności w aplikacjach innych niż aplikacje internetowe, zobacz Wstrzykiwanie zależności na platformie .NET.

Aby uzyskać więcej informacji na temat wstrzykiwania zależności opcji, zobacz Wzorzec opcji w ASP.NET Core.

Ten temat zawiera informacje na temat wstrzykiwania zależności w ASP.NET Core. Podstawowa dokumentacja dotycząca używania wstrzykiwania zależności jest zawarta w iniekcji zależności na platformie .NET.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Omówienie wstrzykiwania zależności

Zależność to obiekt, od którego zależy inny obiekt. Zbadaj następującą MyDependency klasę za pomocą metody, od którego WriteMessage zależą inne klasy:

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

Klasa może utworzyć wystąpienie MyDependency klasy, aby użyć jej WriteMessage metody. W poniższym przykładzie MyDependency klasa jest zależnością IndexModel klasy:

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

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

Klasa tworzy klasę MyDependency i zależy bezpośrednio od klasy . Zależności kodu, takie jak w poprzednim przykładzie, są problematyczne i należy unikać ich z następujących powodów:

• Aby zastąpić MyDependency inną implementacją, należy zmodyfikować klasę IndexModel .
• Jeśli MyDependency mają zależności, muszą być również skonfigurowane przez klasę IndexModel . W dużym projekcie z wieloma klasami w zależności od MyDependencymetody kod konfiguracji staje się rozproszony w całej aplikacji.
• Ta implementacja jest trudna do testowania jednostkowego.

Wstrzykiwanie zależności rozwiązuje następujące problemy, wykonując następujące czynności:

• Użycie interfejsu lub klasy bazowej do abstrakcji implementacji zależności.
• Rejestracja zależności w kontenerze usługi. ASP.NET Core udostępnia wbudowany kontener usługi, IServiceProvider. Usługi są zwykle rejestrowane w pliku aplikacji Program.cs .
• Iniekcja usługi do konstruktora klasy, w której jest używana. Struktura przejmuje odpowiedzialność za utworzenie wystąpienia zależności i usunięcie jej, gdy nie jest już potrzebne.

W przykładowej aplikacjiIMyDependency interfejs definiuje metodę WriteMessage :

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

Ten interfejs jest implementowany przez konkretny typ: MyDependency

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

Przykładowa aplikacja rejestruje usługę IMyDependency przy użyciu konkretnego typu MyDependency. Metoda AddScoped rejestruje usługę z okresem istnienia o określonym zakresie, okresem istnienia pojedynczego żądania. Okresy istnienia usługi są opisane w dalszej części tego tematu.

using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddScoped<IMyDependency, MyDependency>();

var app = builder.Build();

W przykładowej aplikacji IMyDependency usługa jest żądana i używana do wywołania WriteMessage metody :

public class Index2Model : PageModel
{
    private readonly IMyDependency _myDependency;

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

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

Za pomocą wzorca DI kontroler lub Razor strona:

• Nie używa konkretnego typu MyDependency, tylko interfejs, który IMyDependency implementuje. Ułatwia to zmianę implementacji bez modyfikowania kontrolera lub Razor strony.
• Nie tworzy wystąpienia MyDependencyklasy , które jest tworzone przez kontener DI.

Implementację interfejsu IMyDependency można ulepszyć przy użyciu wbudowanego interfejsu API rejestrowania:

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

Zaktualizowany Program.cs rejestruje nową IMyDependency implementację:

using DependencyInjectionSample.Interfaces;
using DependencyInjectionSample.Services;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddScoped<IMyDependency, MyDependency2>();

var app = builder.Build();

MyDependency2 zależy od ILogger<TCategoryName>elementu , który żąda w konstruktorze. ILogger<TCategoryName> jest usługą zapewnianą przez platformę.

Nie jest niczym niezwykłym, aby używać wstrzykiwania zależności w sposób łańcuchowy. Każda żądana zależność z kolei żąda własnych zależności. Kontener rozpoznaje zależności na grafie i zwraca w pełni rozpoznaną usługę. Zbiorczy zestaw zależności, które należy rozpoznać, jest zazwyczaj określany jako drzewo zależności, graf zależności lub graf obiektów.

Kontener rozwiązuje problem ILogger<TCategoryName> dzięki wykorzystaniu (ogólnych) typów otwartych, eliminując konieczność rejestrowania każdego typu skonstruowanego (ogólnego).

W terminologii wstrzykiwania zależności usługa:

• Jest to zazwyczaj obiekt, który zapewnia usługę innym obiektom, takim jak IMyDependency usługa.
• Nie jest powiązana z usługą internetową, chociaż usługa może używać usługi internetowej.

Platforma zapewnia niezawodny system rejestrowania . Implementacje IMyDependency pokazane w poprzednich przykładach zostały napisane w celu zademonstrowania podstawowego di, a nie zaimplementowania rejestrowania. Większość aplikacji nie powinna pisać rejestratorów. Poniższy kod demonstruje użycie rejestrowania domyślnego, które nie wymaga zarejestrowania żadnych usług:

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

Przy użyciu powyższego kodu nie ma potrzeby aktualizowania Program.cselementu , ponieważ rejestrowanie jest udostępniane przez strukturę.

Rejestrowanie grup usług za pomocą metod rozszerzeń

Struktura ASP.NET Core używa konwencji rejestrowania grupy powiązanych usług. Konwencja polega na użyciu jednej Add{GROUP_NAME} metody rozszerzenia do rejestrowania wszystkich usług wymaganych przez funkcję platformy. Na przykład AddControllers metoda rozszerzenia rejestruje usługi wymagane dla kontrolerów MVC.

Poniższy kod jest generowany przez Razor szablon Strony przy użyciu poszczególnych kont użytkowników i pokazuje, jak dodać dodatkowe usługi do kontenera przy użyciu metod AddDbContext rozszerzenia i 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();

Rozważ następujące kwestie, które rejestrują usługi i konfigurują opcje:

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

Powiązane grupy rejestracji można przenieść do metody rozszerzenia, aby zarejestrować usługi. Na przykład usługi konfiguracji są dodawane do następującej klasy:

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

Pozostałe usługi są rejestrowane w podobnej klasie. Poniższy kod używa nowych metod rozszerzenia do rejestrowania usług:

using Microsoft.Extensions.DependencyInjection.ConfigSample.Options;

var builder = WebApplication.CreateBuilder(args);

builder.Services
    .AddConfig(builder.Configuration)
    .AddMyDependencyGroup();

builder.Services.AddRazorPages();

var app = builder.Build();

Uwaga: Każda services.Add{GROUP_NAME} metoda rozszerzenia dodaje i potencjalnie konfiguruje usługi. Na przykład AddControllersWithViews dodaje kontrolery MVC usług z wymaganymi widokami i AddRazorPages dodaje wymagane usługi Razor Pages. Zalecamy, aby aplikacje przestrzegały konwencji nazewnictwa tworzenia metod rozszerzeń w Microsoft.Extensions.DependencyInjection przestrzeni nazw. Tworzenie metod rozszerzeń w Microsoft.Extensions.DependencyInjection przestrzeni nazw:

• Hermetyzuje grupy rejestracji usług.
• Zapewnia wygodny dostęp intelliSense do usługi.

Okresy istnienia usługi

Zobacz Service lifetimes in Dependency injection in .NET (Okresy istnienia usługi w iniekcji zależności na platformie .NET)

Aby użyć usług o określonym zakresie w programie pośredniczącym, użyj jednej z następujących metod:

• Wstrzykiwanie usługi do metody lub InvokeAsync oprogramowania pośredniczącegoInvoke. Użycie iniekcji konstruktora zgłasza wyjątek środowiska uruchomieniowego, ponieważ wymusza działanie usługi o określonym zakresie jak pojedyncza. Przykład w sekcji Opcje okresu istnienia i rejestracji przedstawia InvokeAsync podejście.
• Użyj oprogramowania pośredniczącego opartego na fabryce. Oprogramowanie pośredniczące zarejestrowane przy użyciu tej metody jest aktywowane na żądanie klienta (połączenie), które umożliwia wstrzyknięcie usług o określonym zakresie do konstruktora oprogramowania pośredniczącego.

Aby uzyskać więcej informacji, zobacz Pisanie niestandardowego oprogramowania pośredniczącego ASP.NET Core.

Metody rejestracji usług

Zobacz Metody rejestracji usługi w iniekcji zależności na platformie .NET

Często używa się wielu implementacji podczas pozorowania typów do testowania.

Zarejestrowanie usługi tylko z typem implementacji jest równoważne zarejestrowaniu tej usługi z tą samą implementacją i typem usługi. Dlatego nie można zarejestrować wielu implementacji usługi przy użyciu metod, które nie przyjmują jawnego typu usługi. Te metody mogą rejestrować wiele wystąpień usługi, ale wszystkie będą miały ten sam typ implementacji .

Każda z powyższych metod rejestracji usług może służyć do rejestrowania wielu wystąpień usługi tego samego typu usługi. W poniższym przykładzie AddSingleton element jest wywoływany dwa razy z IMyDependency typem usługi. Drugie wywołanie AddSingleton zastąpi poprzednie po rozwiązaniu jako IMyDependency i dodaje do poprzedniego, gdy wiele usług jest rozpoznawanych za pośrednictwem metody IEnumerable<IMyDependency>. Usługi są wyświetlane w kolejności, w której zostały zarejestrowane po rozwiązaniu za pośrednictwem .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);
    }
}

Zachowanie iniekcji konstruktora

Zobacz Zachowanie iniekcji konstruktora w iniekcji zależności na platformie .NET

Konteksty programu Entity Framework

Domyślnie konteksty programu Entity Framework są dodawane do kontenera usługi przy użyciu okresu istnienia o określonym zakresie , ponieważ operacje bazy danych aplikacji internetowej są zwykle ograniczone do żądania klienta. Aby użyć innego okresu istnienia, określ okres istnienia przy użyciu AddDbContext przeciążenia. Usługi danego okresu istnienia nie powinny używać kontekstu bazy danych z okresem istnienia krótszym niż okres istnienia usługi.

Opcje okresu istnienia i rejestracji

Aby zademonstrować różnicę między okresami istnienia usługi a ich opcjami rejestracji, należy wziąć pod uwagę następujące interfejsy reprezentujące zadanie jako operację z identyfikatorem OperationId. W zależności od tego, jak okres istnienia usługi operacji jest skonfigurowany dla następujących interfejsów, kontener udostępnia te same lub różne wystąpienia usługi w przypadku żądania klasy:

public interface IOperation
{
    string OperationId { get; }
}

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

Poniższa Operation klasa implementuje wszystkie poprzednie interfejsy. Konstruktor Operation generuje identyfikator GUID i przechowuje ostatnie 4 znaki we OperationId właściwości :

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

    public string OperationId { get; }
}

Poniższy kod tworzy wiele rejestracji Operation klasy zgodnie z nazwanych okresów istnienia:

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

Przykładowa aplikacja demonstruje okresy istnienia obiektów zarówno wewnątrz, jak i między żądaniami. Oprogramowanie IndexModel pośredniczące i żąda każdego typu i rejestrują OperationId dla każdego z IOperation nich:

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

Podobnie jak w przypadku IndexModelprogramu , oprogramowanie pośredniczące rozwiązuje te same usługi:

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

W metodzie należy rozpoznać usługi o określonym zakresie i przejściowym 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);
}

Dane wyjściowe rejestratora pokazują:

• Obiekty przejściowe są zawsze różne. Wartość przejściowa OperationId różni się w zmiennej IndexModel i w oprogramowania pośredniczącego.
• Obiekty o określonym zakresie są takie same dla danego żądania, ale różnią się w zależności od każdego nowego żądania.
• Pojedyncze obiekty są takie same dla każdego żądania.

Aby zmniejszyć dane wyjściowe rejestrowania, w pliku ustaw wartość "Logging:LogLevel:Microsoft:Error" appsettings.Development.json :

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

Rozwiązywanie problemów z usługą podczas uruchamiania aplikacji

Poniższy kod pokazuje, jak rozwiązać problem z usługą o określonym zakresie przez ograniczony czas trwania podczas uruchamiania aplikacji:

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

Sprawdzanie poprawności zakresu

Zobacz Zachowanie iniekcji konstruktora w iniekcji zależności na platformie .NET

Aby uzyskać więcej informacji, zobacz Sprawdzanie poprawności zakresu.

Żądania usług

Usługi i ich zależności w ramach żądania ASP.NET Core są udostępniane za pośrednictwem usługi HttpContext.RequestServices.

Struktura tworzy zakres na żądanie i RequestServices uwidacznia dostawcę usług o określonym zakresie. Wszystkie usługi o określonym zakresie są prawidłowe tak długo, jak żądanie jest aktywne.

Uwaga

Preferuj żądanie zależności jako parametrów konstruktora w przypadku rozpoznawania usług z programu RequestServices. Żądanie zależności jako parametrów konstruktora daje klasy, które są łatwiejsze do przetestowania.

Usługi projektowania pod kątem wstrzykiwania zależności

Podczas projektowania usług do wstrzykiwania zależności:

• Unikaj stanowych, statycznych klas i składowych. Unikaj tworzenia stanu globalnego, projektując aplikacje do używania pojedynczych usług.
• Unikaj bezpośredniego tworzenia wystąpień klas zależnych w ramach usług. Bezpośrednie tworzenie wystąpień łączy kod z określoną implementacją.
• Zadbaj o to, aby usługi były małe, dobrze uwzględniane i łatwo testowane.

Jeśli klasa ma wiele wstrzykiwanych zależności, może to być znak, że klasa ma zbyt wiele obowiązków i narusza zasadę o pojedynczej odpowiedzialności (SRP). Spróbuj refaktoryzować klasę, przenosząc część swoich obowiązków do nowych klas. Należy pamiętać, że Razor klasy modeli stron stron i klasy kontrolerów MVC powinny skupić się na kwestiach interfejsu użytkownika.

Usuwanie usług

Kontener wywołuje Dispose typy, które IDisposable tworzy. Usługi rozwiązane z kontenera nigdy nie powinny być usuwane przez dewelopera. Jeśli typ lub fabryka jest rejestrowana jako pojedyncza, kontener automatycznie usuwa pojedynczy element.

W poniższym przykładzie usługi są tworzone przez kontener usługi i usuwane automatycznie: dependency-injection\samples\6.x\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");
    }
}

Konsola debugowania wyświetla następujące dane wyjściowe po każdym odświeżeniu strony Indeks:

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

Usługi nie są tworzone przez kontener usługi

Spójrzmy na poniższy kod:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

builder.Services.AddSingleton(new Service1());
builder.Services.AddSingleton(new Service2());

Powyższy kod ma następujące działanie:

• Wystąpienia usługi nie są tworzone przez kontener usługi.
• Platforma nie usuwa automatycznie usług.
• Deweloper jest odpowiedzialny za rozpowszechnianie usług.

Wskazówki dotyczące interfejsu IDisposable dla wystąpień przejściowych i udostępnionych

Zobacz IDisposable guidance for Transient and shared instance in Dependency injection in .NET (Wskazówki dotyczące interfejsu IDisposable dla przejściowego i współużytkowanego wystąpienia w iniekcji zależności na platformie .NET)

Domyślne zastępowanie kontenera usługi

Zobacz Domyślne zastępowanie kontenera usługi w iniekcji zależności na platformie .NET

Zalecenia

Zobacz Zalecenia dotyczące wstrzykiwania zależności na platformie .NET

• Unikaj używania wzorca lokalizatora usług. Na przykład nie należy wywoływać GetService w celu uzyskania wystąpienia usługi, gdy można użyć di zamiast tego:

  Niepoprawnie:

  

  Odpowiedź prawidłowa:

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

• Kolejna odmiana lokalizatora usług w celu uniknięcia polega na wstrzyknięciu fabryki, która rozwiązuje zależności w czasie wykonywania. Oba te rozwiązania mieszają inwersję strategii kontroli .

• Unikaj dostępu statycznego do HttpContext (na przykład IHttpContextAccessor.HttpContext).

Di to alternatywa dla wzorców dostępu do obiektów statycznych/globalnych. Możesz nie być w stanie zrealizować korzyści z di, jeśli mieszasz go z dostępem do obiektów statycznych.

Zalecane wzorce dla wielu dzierżaw w usłudze DI

Orchard Core to struktura aplikacji do tworzenia modułowych, wielodostępnych aplikacji na ASP.NET Core. Aby uzyskać więcej informacji, zobacz dokumentację Sad Core.

Zapoznaj się z przykładami aplikacji Orchard Core , aby zapoznać się z przykładami tworzenia modułowych i wielodostępnych aplikacji korzystających tylko z platformy Sad Core Framework bez żadnych funkcji specyficznych dla systemu CMS.

Usługi dostarczane przez platformę

Program.csrejestruje usługi używane przez aplikację, w tym funkcje platformy, takie jak Entity Framework Core i ASP.NET Core MVC. Początkowo udostępniany Program.cs element IServiceCollection zawiera usługi zdefiniowane przez strukturę w zależności od sposobu konfigurowania hosta. W przypadku aplikacji opartych na szablonach ASP.NET Core platforma rejestruje ponad 250 usług.

W poniższej tabeli przedstawiono niewielką próbkę tych usług zarejestrowanych w strukturze:

Typ usługi	Okres istnienia
Microsoft.AspNetCore.Hosting.Builder.IApplicationBuilderFactory	Przejściowy
IHostApplicationLifetime	Singleton
IWebHostEnvironment	Singleton
Microsoft.AspNetCore.Hosting.IStartup	Singleton
Microsoft.AspNetCore.Hosting.IStartupFilter	Przejściowy
Microsoft.AspNetCore.Hosting.Server.IServer	Singleton
Microsoft.AspNetCore.Http.IHttpContextFactory	Przejściowy
Microsoft.Extensions.Logging.ILogger<TCategoryName>	Singleton
Microsoft.Extensions.Logging.ILoggerFactory	Singleton
Microsoft.Extensions.ObjectPool.ObjectPoolProvider	Singleton
Microsoft.Extensions.Options.IConfigureOptions<TOptions>	Przejściowy
Microsoft.Extensions.Options.IOptions<TOptions>	Singleton
System.Diagnostics.DiagnosticSource	Singleton
System.Diagnostics.DiagnosticListener	Singleton

Dodatkowe zasoby

• Wstrzykiwanie zależności do widoków w ASP.NET Core
• Wstrzykiwanie zależności do kontrolerów w ASP.NET Core
• Wstrzykiwanie zależności w programach obsługi wymagań w ASP.NET Core
• Blazor wstrzykiwanie zależności ASP.NET Core
• Wzorce konferencji NDC na potrzeby tworzenia aplikacji di
• Uruchamianie aplikacji w ASP.NET Core
• Aktywacja oprogramowania pośredniczącego opartego na fabryce w ASP.NET Core
• Cztery sposoby usuwania obiektów IDisposable w ASP.NET Core
• Pisanie czystego kodu w ASP.NET Core za pomocą wstrzykiwania zależności (MSDN)
• Zasada jawnych zależności
• Inwersja kontenerów kontrolek i wzorzec wstrzykiwania zależności (Martin Fowler)
• Jak zarejestrować usługę za pomocą wielu interfejsów w usłudze ASP.NET Core DI

Przez Kirk Larkin, Steve Smith, Scott Addie i Brandon Dahler

ASP.NET Core obsługuje wzorzec projektowania oprogramowania wstrzykiwania zależności (DI), który jest techniką osiągnięcia inwersji kontroli (IoC) między klasami i ich zależnościami.

Aby uzyskać więcej informacji specyficznych dla wstrzykiwania zależności w kontrolerach MVC, zobacz Wstrzykiwanie zależności do kontrolerów w ASP.NET Core.

Aby uzyskać informacje na temat używania iniekcji zależności w aplikacjach innych niż aplikacje internetowe, zobacz Wstrzykiwanie zależności na platformie .NET.

Aby uzyskać więcej informacji na temat wstrzykiwania zależności opcji, zobacz Wzorzec opcji w ASP.NET Core.

Ten temat zawiera informacje na temat iniekcji zależności w ASP.NET Core. Podstawowa dokumentacja dotycząca używania iniekcji zależności znajduje się w iniekcji zależności na platformie .NET.

Wyświetl lub pobierz przykładowy kod (jak pobrać)

Omówienie wstrzykiwania zależności

Zależność to obiekt, od którego zależy inny obiekt. Zbadaj następującą MyDependency klasę WriteMessage przy użyciu metody, od których zależą inne klasy:

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

Klasa może utworzyć wystąpienie MyDependency klasy, aby korzystać z jej WriteMessage metody. W poniższym przykładzie MyDependency klasa jest zależnością IndexModel klasy:

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

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

Klasa tworzy i zależy bezpośrednio od MyDependency klasy. Zależności kodu, takie jak w poprzednim przykładzie, są problematyczne i należy unikać z następujących powodów:

• Aby zastąpić MyDependency inną implementacją, IndexModel należy zmodyfikować klasę.
• Jeśli MyDependency mają zależności, muszą być również skonfigurowane przez klasę IndexModel . W dużym projekcie z wieloma klasami w zależności od MyDependencyprogramu kod konfiguracji staje się rozrzucony w całej aplikacji.
• Ta implementacja jest trudna do przetestowania jednostkowego. Aplikacja powinna używać makiety lub klasy wycinkowej MyDependency , która nie jest możliwa w przypadku tego podejścia.

Iniekcja zależności rozwiązuje następujące problemy za pomocą następujących czynności:

• Użycie interfejsu lub klasy bazowej do abstrakcji implementacji zależności.
• Rejestracja zależności w kontenerze usługi. ASP.NET Core udostępnia wbudowany kontener usługi . IServiceProvider Usługi są zwykle rejestrowane w metodzie aplikacji Startup.ConfigureServices .
• Iniekcja usługi do konstruktora klasy, w której jest używana. Struktura bierze na siebie odpowiedzialność za utworzenie wystąpienia zależności i dysponowanie jej, gdy nie jest już potrzebne.

W przykładowej aplikacjiIMyDependency interfejs definiuje metodęWriteMessage:

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

Ten interfejs jest implementowany przez konkretny typ: MyDependency

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

Przykładowa aplikacja rejestruje usługę IMyDependency przy użyciu konkretnego typu MyDependency. Metoda AddScoped rejestruje usługę z okresem istnienia o określonym zakresie, okresem istnienia pojedynczego żądania. Okresy istnienia usługi zostały opisane w dalszej części tego tematu.

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

    services.AddRazorPages();
}

W przykładowej aplikacji IMyDependency usługa jest żądana i używana do wywoływania WriteMessage metody:

public class Index2Model : PageModel
{
    private readonly IMyDependency _myDependency;

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

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

Korzystając ze wzorca di, kontroler:

• Nie używa konkretnego typu MyDependency, tylko interfejs, który IMyDependency implementuje. Ułatwia to zmianę implementacji używanej przez kontroler bez modyfikowania kontrolera.
• Nie tworzy wystąpienia klasy MyDependency, które jest tworzone przez kontener DI.

Implementacja interfejsu IMyDependency może zostać ulepszona przy użyciu wbudowanego interfejsu API rejestrowania:

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

Zaktualizowana ConfigureServices metoda rejestruje nową IMyDependency implementację:

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

    services.AddRazorPages();
}

MyDependency2 zależy od ILogger<TCategoryName>obiektu , który żąda w konstruktorze. ILogger<TCategoryName> to usługa zapewniana przez platformę.

Nie jest niczym niezwykłym, aby używać wstrzykiwania zależności w sposób łańcuchowy. Każda żądana zależność z kolei żąda własnych zależności. Kontener rozpoznaje zależności na wykresie i zwraca w pełni rozpoznaną usługę. Zbiorczy zestaw zależności, które należy rozwiązać, jest zazwyczaj określany jako drzewo zależności, graf zależności lub graf obiektu.

Kontener rozwiązuje problem ILogger<TCategoryName> dzięki wykorzystaniu (ogólnych) typów otwartych, eliminując konieczność rejestrowania każdego typu skonstruowanego (ogólnego).

W terminologii iniekcji zależności usługa:

• Jest to zazwyczaj obiekt, który zapewnia usługę innym obiektom, takim jak IMyDependency usługa.
• Nie jest powiązana z usługą internetową, chociaż usługa może używać usługi internetowej.

Platforma zapewnia niezawodny system rejestrowania . Implementacje IMyDependency przedstawione w poprzednich przykładach zostały napisane w celu zademonstrowania podstawowego di, a nie zaimplementowania rejestrowania. Większość aplikacji nie powinna pisać rejestratorów. Poniższy kod pokazuje użycie domyślnego rejestrowania, które nie wymaga zarejestrowania żadnych usług w programie 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);
    }
}

Przy użyciu poprzedniego kodu nie ma potrzeby aktualizowania ConfigureServiceselementu , ponieważ rejestrowanie jest udostępniane przez platformę.

Usługi wprowadzone do uruchamiania

Usługi można wstrzyknąć do konstruktora StartupStartup.Configure i metody.

Tylko następujące usługi można wstrzyknąć do konstruktora Startup przy użyciu hosta ogólnego (IHostBuilder):

• IWebHostEnvironment
• IHostEnvironment
• IConfiguration

Do metody można wprowadzić dowolną usługę zarejestrowaną w kontenerze Startup.Configure DI:

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

Aby uzyskać więcej informacji, zobacz Uruchamianie aplikacji w ASP.NET Core i Konfiguracja dostępu w uruchamianiu.

Rejestrowanie grup usług za pomocą metod rozszerzeń

Struktura ASP.NET Core używa konwencji rejestrowania grupy powiązanych usług. Konwencja polega na użyciu jednej Add{GROUP_NAME} metody rozszerzenia do rejestrowania wszystkich usług wymaganych przez funkcję platformy. Na przykład AddControllers metoda rozszerzenia rejestruje usługi wymagane dla kontrolerów MVC.

Poniższy kod jest generowany przez Razor szablon Strony przy użyciu poszczególnych kont użytkowników i pokazuje, jak dodać dodatkowe usługi do kontenera przy użyciu metod AddDbContext rozszerzeń i 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();
}

Rozważmy następującą ConfigureServices metodę, która rejestruje usługi i konfiguruje opcje:

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

Powiązane grupy rejestracji można przenieść do metody rozszerzenia w celu zarejestrowania usług. Na przykład usługi konfiguracji są dodawane do następującej klasy:

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

Pozostałe usługi są rejestrowane w podobnej klasie. ConfigureServices Poniższa metoda używa nowych metod rozszerzenia do rejestrowania usług:

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

    services.AddRazorPages();
}

Uwaga: Każda services.Add{GROUP_NAME} metoda rozszerzenia dodaje i potencjalnie konfiguruje usługi. Na przykład AddControllersWithViews dodaje kontrolery MVC usług z wymaganymi widokami i AddRazorPages dodaje wymagane usługi Razor Pages. Zalecamy, aby aplikacje przestrzegały konwencji nazewnictwa tworzenia metod rozszerzeń w Microsoft.Extensions.DependencyInjection przestrzeni nazw. Tworzenie metod rozszerzeń w Microsoft.Extensions.DependencyInjection przestrzeni nazw:

• Hermetyzuje grupy rejestracji usług.
• Zapewnia wygodny dostęp do usługi IntelliSense .

Okresy istnienia usługi

Zobacz Okresy istnienia usługi w iniekcji zależności na platformie .NET

Aby użyć usług o określonym zakresie w programie pośredniczącym, użyj jednego z następujących metod:

• Wstrzykiwanie usługi do metody lub InvokeAsync oprogramowania Invoke pośredniczącego. Użycie iniekcji konstruktora zgłasza wyjątek środowiska uruchomieniowego, ponieważ wymusza zachowanie usługi o określonym zakresie w taki sposób, jak pojedyncza. Przykład w sekcji Opcje okresu istnienia i rejestracji przedstawia InvokeAsync podejście.
• Użyj oprogramowania pośredniczącego opartego na fabryce. Oprogramowanie pośredniczące zarejestrowane przy użyciu tego podejścia jest aktywowane na żądanie klienta (połączenie), co umożliwia wstrzyknięcie usług o określonym zakresie do metody oprogramowania pośredniczącego InvokeAsync .

Aby uzyskać więcej informacji, zobacz Pisanie niestandardowego oprogramowania pośredniczącego ASP.NET Core.

Metody rejestracji usługi

Zobacz Metody rejestracji usługi w iniekcji zależności na platformie .NET

Często używa się wielu implementacji podczas pozorowania typów do testowania.

Zarejestrowanie usługi tylko z typem implementacji jest równoważne zarejestrowaniu tej usługi z tą samą implementacją i typem usługi. Dlatego nie można zarejestrować wielu implementacji usługi przy użyciu metod, które nie przyjmują jawnego typu usługi. Te metody mogą rejestrować wiele wystąpień usługi, ale wszystkie będą miały ten sam typ implementacji .

Dowolna z powyższych metod rejestracji usługi może służyć do rejestrowania wielu wystąpień usługi tego samego typu usługi. W poniższym przykładzie AddSingleton jest wywoływana dwukrotnie z IMyDependency typem usługi. Drugie wywołanie AddSingleton przesłoni poprzednią po rozwiązaniu jako IMyDependency i dodaje do poprzedniej, gdy wiele usług jest rozpoznawanych za pośrednictwem metody IEnumerable<IMyDependency>. Usługi są wyświetlane w kolejności, w której zostały zarejestrowane po rozwiązaniu za pośrednictwem polecenia 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);
    }
}

Zachowanie iniekcji konstruktora

Zobacz Zachowanie iniekcji konstruktoraw iniekcji zależności na platformie .NET

Konteksty platformy Entity Framework

Domyślnie konteksty platformy Entity Framework są dodawane do kontenera usługi przy użyciu okresu istnienia, ponieważ operacje bazy danych aplikacji internetowej są zwykle ograniczone do żądania klienta. Aby użyć innego okresu istnienia, określ okres istnienia przy użyciu AddDbContext przeciążenia. Usługi danego okresu istnienia nie powinny używać kontekstu bazy danych z okresem istnienia krótszym niż okres istnienia usługi.

Opcje okresu istnienia i rejestracji

Aby zademonstrować różnicę między okresami istnienia usługi a ich opcjami rejestracji, rozważ następujące interfejsy reprezentujące zadanie jako operację z identyfikatorem OperationId. W zależności od tego, jak okres istnienia usługi operacji jest skonfigurowany dla następujących interfejsów, kontener udostępnia te same lub różne wystąpienia usługi w przypadku żądania przez klasę:

public interface IOperation
{
    string OperationId { get; }
}

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

Poniższa Operation klasa implementuje wszystkie poprzednie interfejsy. Konstruktor Operation generuje identyfikator GUID i przechowuje ostatnie 4 znaki we OperationId właściwości:

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

    public string OperationId { get; }
}

Metoda Startup.ConfigureServices tworzy wiele rejestracji Operation klasy zgodnie z nazwami okresami istnienia:

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

    services.AddRazorPages();
}

Przykładowa aplikacja demonstruje okres istnienia obiektów zarówno wewnątrz, jak i między żądaniami. I IndexModel oprogramowanie pośredniczące żąda każdego typu IOperation i rejestruje OperationId dla każdego typu:

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

Podobnie jak w przypadku IndexModelprogramu , oprogramowanie pośredniczące rozwiązuje te same usługi:

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

Usługi o określonym zakresie należy rozpoznać w metodzie 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);
}

Dane wyjściowe rejestratora pokazują:

• Obiekty przejściowe są zawsze różne. Wartość przejściowa OperationId różni się w IndexModel i w oprogramowania pośredniczącego.
• Obiekty o określonym zakresie są takie same dla danego żądania, ale różnią się między poszczególnymi nowymi żądaniami.
• Pojedyncze obiekty są takie same dla każdego żądania.

Aby zmniejszyć dane wyjściowe rejestrowania, ustaw wartość "Logging:LogLevel:Microsoft:Error" w appsettings.Development.json pliku:

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

Połączenia z usług głównych

Utwórz element IServiceScope za pomocą elementu IServiceScopeFactory.CreateScope , aby rozwiązać problem z usługą o określonym zakresie w zakresie aplikacji. Takie podejście jest przydatne do uzyskiwania dostępu do usługi o określonym zakresie podczas uruchamiania w celu uruchamiania zadań inicjowania.

W poniższym przykładzie pokazano, jak uzyskać dostęp do usługi o IMyDependency określonym zakresie i wywołać jej WriteMessage metodę w programie Program.Main:

public class Program
{
    public static void Main(string[] args)
    {
        var host = CreateHostBuilder(args).Build();

        using (var serviceScope = host.Services.CreateScope())
        {
            var services = serviceScope.ServiceProvider;

            try
            {
                var myDependency = services.GetRequiredService<IMyDependency>();
                myDependency.WriteMessage("Call services from main");
            }
            catch (Exception ex)
            {
                var logger = services.GetRequiredService<ILogger<Program>>();
                logger.LogError(ex, "An error occurred.");
            }
        }

        host.Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

Walidacja zakresu

Zobacz Zachowanie iniekcji konstruktoraw iniekcji zależności na platformie .NET

Aby uzyskać więcej informacji, zobacz Sprawdzanie poprawności zakresu.

Żądania usług

Usługi i ich zależności w ramach żądania ASP.NET Core są udostępniane za pośrednictwem HttpContext.RequestServicesprogramu .

Struktura tworzy zakres na żądanie i RequestServices uwidacznia dostawcę usług o określonym zakresie. Wszystkie usługi o określonym zakresie są prawidłowe pod warunkiem, że żądanie jest aktywne.

Uwaga

Preferuj żądanie zależności jako parametry konstruktora w przypadku rozpoznawania usług z RequestServicesprogramu . Żądanie zależności jako parametrów konstruktora daje klasy, które są łatwiejsze do przetestowania.

Usługi projektowe do wstrzykiwania zależności

Podczas projektowania usług do wstrzykiwania zależności:

• Unikaj stanowych, statycznych klas i elementów członkowskich. Unikaj tworzenia stanu globalnego, projektując aplikacje, aby zamiast tego używać usług singleton.
• Unikaj bezpośredniego tworzenia wystąpień klas zależnych w ramach usług. Bezpośrednie wystąpienie łączy kod z określoną implementacją.
• Zrób usługi małe, dobrze uwzględniane i łatwo testowane.

Jeśli klasa ma wiele wstrzykiwanych zależności, może to oznaczać, że klasa ma zbyt wiele obowiązków i narusza zasadę odpowiedzialności pojedynczej (SRP). Spróbuj refaktoryzować klasę, przenosząc niektóre z jego obowiązków do nowych klas. Należy pamiętać, że Razor klasy modeli stron stron i klasy kontrolerów MVC powinny skupić się na problemach z interfejsem użytkownika.

Usuwanie usług

Kontener wywołuje DisposeIDisposable typy, które tworzy. Usługi rozwiązane z kontenera nigdy nie powinny być usuwane przez dewelopera. Jeśli typ lub fabryka jest rejestrowana jako pojedyncza, kontener automatycznie usuwa pojedynczyton.

W poniższym przykładzie usługi są tworzone przez kontener usługi i usuwane automatycznie:

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

Konsola debugowania wyświetla następujące dane wyjściowe po każdym odświeżeniu strony Indeks:

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

Usługi nie są tworzone przez kontener usługi

Spójrzmy na poniższy kod:

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

    services.AddRazorPages();
}

Powyższy kod ma następujące działanie:

• Wystąpienia usługi nie są tworzone przez kontener usługi.
• Struktura nie usuwa automatycznie usług.
• Deweloper jest odpowiedzialny za dysponowanie usług.

Wskazówki dotyczące interfejsu IDisposable dla wystąpień przejściowych i udostępnionych

Zobacz IDisposable guidance for Transient and shared instance in dependency injection in .NET (Wskazówki dotyczące interfejsu IDisposable dotyczące przejściowego i współużytkowanego wystąpienia w iniekcji zależności na platformie .NET)

Domyślna wymiana kontenera usługi

Zobacz Domyślne zastępowanie kontenera usługi w iniekcji zależności na platformie .NET

Zalecenia

Zobacz Zalecenia w iniekcji zależności na platformie .NET

• Unikaj używania wzorca lokalizatora usług. Nie należy na przykład wywoływać wywołania GetService w celu uzyskania wystąpienia usługi, gdy zamiast tego można użyć di:

  Niepoprawnie:

  

  Odpowiedź prawidłowa:

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

• Inną odmianą lokalizatora usług, aby uniknąć, jest wstrzykiwanie fabryki, która rozwiązuje zależności w czasie wykonywania. Obie te praktyki mieszają inwersję strategii kontroli .

• Unikaj dostępu statycznego do HttpContext (na przykład IHttpContextAccessor.HttpContext).

• Unikaj wywołań w BuildServiceProvider pliku ConfigureServices. Wywoływanie BuildServiceProvider zwykle występuje, gdy deweloper chce rozwiązać usługę w programie ConfigureServices. Rozważmy na przykład przypadek, w którym LoginPath element jest ładowany z konfiguracji. Unikaj następującego podejścia:

  

  Na poprzedniej ilustracji wybranie zielonej linii falistej poniżej services.BuildServiceProvider pokazuje następujące ostrzeżenie ASP0000:

  Wywołanie elementu "BuildServiceProvider" na podstawie kodu aplikacji asp0000 powoduje utworzenie dodatkowej kopii tworzonych usług jednotonowych. Rozważ alternatywy, takie jak wstrzykiwanie usług zależności jako parametry do konfiguracji.

  Wywołanie BuildServiceProvider tworzy drugi kontener, który może tworzyć rozdarte pojedynczetony i powodować odwołania do grafów obiektów w wielu kontenerach.

  Prawidłowym sposobem uzyskania LoginPath jest użycie wbudowanej obsługi wzorca opcji dla 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();
  }
  

• Jednorazowe usługi przejściowe są przechwytywane przez kontener do usuwania. Może to przekształcić się w wyciek pamięci, jeśli zostanie rozwiązany z kontenera najwyższego poziomu.

• Włącz walidację zakresu, aby upewnić się, że aplikacja nie ma pojedynczych dysków, które przechwytują usługi o określonym zakresie. Aby uzyskać więcej informacji, zobacz Sprawdzanie poprawności zakresu.

Podobnie jak w przypadku wszystkich zestawów zaleceń, mogą wystąpić sytuacje, w których jest wymagane ignorowanie zalecenia. Wyjątki są rzadkie, głównie specjalne przypadki w samej strukturze.

Di to alternatywa dla wzorców dostępu do obiektów statycznych/globalnych. W przypadku połączenia z dostępem do obiektów statycznych może nie być możliwe zrealizowanie korzyści związanych z di.

Zalecane wzorce dla wielu dzierżaw w di

Orchard Core to struktura aplikacji do tworzenia modułowych, wielodostępnych aplikacji na ASP.NET Core. Aby uzyskać więcej informacji, zobacz dokumentację Sad Core.

Zobacz przykłady aplikacji Orchard Core, aby zapoznać się z przykładami tworzenia aplikacji modułowych i wielodostępnych przy użyciu tylko platformy Orchard Core Framework bez żadnych funkcji specyficznych dla usługi CMS.

Usługi dostarczane przez platformę

Metoda Startup.ConfigureServices rejestruje usługi używane przez aplikację, w tym funkcje platformy, takie jak Entity Framework Core i ASP.NET Core MVC. IServiceCollection Początkowo udostępniany element ConfigureServices ma usługi zdefiniowane przez platformę w zależności od sposobu konfigurowania hosta. W przypadku aplikacji opartych na szablonach ASP.NET Core platforma rejestruje ponad 250 usług.

W poniższej tabeli przedstawiono małą próbkę tych usług zarejestrowanych w strukturze:

Typ usługi	Okres istnienia
Microsoft.AspNetCore.Hosting.Builder.IApplicationBuilderFactory	Przejściowy
IHostApplicationLifetime	Singleton
IWebHostEnvironment	Singleton
Microsoft.AspNetCore.Hosting.IStartup	Singleton
Microsoft.AspNetCore.Hosting.IStartupFilter	Przejściowy
Microsoft.AspNetCore.Hosting.Server.IServer	Singleton
Microsoft.AspNetCore.Http.IHttpContextFactory	Przejściowy
Microsoft.Extensions.Logging.ILogger<TCategoryName>	Singleton
Microsoft.Extensions.Logging.ILoggerFactory	Singleton
Microsoft.Extensions.ObjectPool.ObjectPoolProvider	Singleton
Microsoft.Extensions.Options.IConfigureOptions<TOptions>	Przejściowy
Microsoft.Extensions.Options.IOptions<TOptions>	Singleton
System.Diagnostics.DiagnosticSource	Singleton
System.Diagnostics.DiagnosticListener	Singleton

Dodatkowe zasoby

• Wstrzykiwanie zależności do widoków w ASP.NET Core
• Wstrzykiwanie zależności do kontrolerów w ASP.NET Core
• Wstrzykiwanie zależności w programach obsługi wymagań w ASP.NET Core
• Blazor ASP.NET Core wstrzykiwanie zależności
• Wzorce konferencji NDC na potrzeby tworzenia aplikacji di
• Uruchamianie aplikacji w ASP.NET Core
• Aktywacja oprogramowania pośredniczącego opartego na fabryce w ASP.NET Core
• Cztery sposoby usuwania obiektów IDisposable w ASP.NET Core
• Pisanie czystego kodu w ASP.NET Core za pomocą wstrzykiwania zależności (MSDN)
• Jawna zasada zależności
• Inwersja kontenerów kontrolek i wzorzec wstrzykiwania zależności (Martin Fowler)
• Jak zarejestrować usługę za pomocą wielu interfejsów w usłudze ASP.NET Core DI