Den här webbläsaren stöds inte längre.
Uppgradera till Microsoft Edge och dra nytta av de senaste funktionerna och säkerhetsuppdateringarna, samt teknisk support.
Den här artikeln innehåller allmänna riktlinjer och metodtips för att implementera beroendeinmatning i .NET-program.
När du utformar tjänster för beroendeinjektion:
Om en klass har många inmatade beroenden kan det vara ett tecken på att klassen har för många ansvarsområden och bryter mot SRP (Single Responsibility Principle). Försök att omstrukturera klassen genom att flytta en del av dess ansvarsområden till nya klasser.
Containern ansvarar för rensning av typer den skapar och anropar Dispose på IDisposable-instanser. Tjänster som löses från containern bör aldrig tas bort av utvecklaren. Om en typ eller fabrik registreras som en singleton tas singletonen bort automatiskt av containern.
I följande exempel skapas tjänsterna av tjänstcontainern och tas bort automatiskt:
namespace ConsoleDisposable.Example;
public sealed class TransientDisposable : IDisposable
{
public void Dispose() => Console.WriteLine($"{nameof(TransientDisposable)}.Dispose()");
}
Den föregående engångsartikeln är avsedd att ha en tillfällig livslängd.
namespace ConsoleDisposable.Example;
public sealed class ScopedDisposable : IDisposable
{
public void Dispose() => Console.WriteLine($"{nameof(ScopedDisposable)}.Dispose()");
}
Ovanstående engångsartikel är avsedd att ha en begränsad livslängd.
namespace ConsoleDisposable.Example;
public sealed class SingletonDisposable : IDisposable
{
public void Dispose() => Console.WriteLine($"{nameof(SingletonDisposable)}.Dispose()");
}
Den föregående engångsartikeln är utformad för att ha en unik livslängd.
using ConsoleDisposable.Example;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
HostApplicationBuilder builder = Host.CreateApplicationBuilder(args);
builder.Services.AddTransient<TransientDisposable>();
builder.Services.AddScoped<ScopedDisposable>();
builder.Services.AddSingleton<SingletonDisposable>();
using IHost host = builder.Build();
ExemplifyDisposableScoping(host.Services, "Scope 1");
Console.WriteLine();
ExemplifyDisposableScoping(host.Services, "Scope 2");
Console.WriteLine();
await host.RunAsync();
static void ExemplifyDisposableScoping(IServiceProvider services, string scope)
{
Console.WriteLine($"{scope}...");
using IServiceScope serviceScope = services.CreateScope();
IServiceProvider provider = serviceScope.ServiceProvider;
_ = provider.GetRequiredService<TransientDisposable>();
_ = provider.GetRequiredService<ScopedDisposable>();
_ = provider.GetRequiredService<SingletonDisposable>();
}
Felsökningskonsolen visar följande exempelutdata när du har kört:
Scope 1...
ScopedDisposable.Dispose()
TransientDisposable.Dispose()
Scope 2...
ScopedDisposable.Dispose()
TransientDisposable.Dispose()
info: Microsoft.Hosting.Lifetime[0]
Application started.Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
Content root path: .\configuration\console-di-disposable\bin\Debug\net5.0
info: Microsoft.Hosting.Lifetime[0]
Application is shutting down...
SingletonDisposable.Dispose()
Ta följande kod som exempel:
// Register example service in IServiceCollection
builder.Services.AddSingleton(new ExampleService());
I koden ovan:
ExampleService skapas inte av tjänstcontainern.Scenario
Appen kräver en IDisposable instans med en tillfällig livslängd för något av följande scenarier:
Lösning
Använd fabriksmönstret för att skapa en instans utanför det överordnade omfånget. I den här situationen skulle appen vanligtvis ha en Create metod som anropar den slutliga typens konstruktor direkt. Om den slutliga typen har andra beroenden kan fabriken:
Scenario
Appen kräver en delad IDisposable instans för flera tjänster, men instansen IDisposable bör ha en begränsad livslängd.
Lösning
Registrera instansen med en begränsad livslängd. Använd IServiceScopeFactory.CreateScope för att skapa en ny IServiceScope. Använd omfånget IServiceProvider för att erhålla nödvändiga tjänster. Ta bort scopet när det inte längre behövs.
Mer information om resursrensning finns i Implementera en Dispose metod eller Implementera en DisposeAsync metod. Tänk också på de disponibla tillfälliga tjänster som fångas upp av containerscenariot när det gäller resursrensning.
Den inbyggda tjänstcontainern är utformad för att uppfylla behoven i ramverket och de flesta konsumentappar. Vi rekommenderar att du använder den inbyggda containern om du inte behöver en specifik funktion som den inte stöder, till exempel:
Func<T> stöd för lat initieringFöljande containrar från tredje part kan användas med ASP.NET Core-appar:
Skapa trådsäkra singleton-tjänster. Om en singleton-tjänst har ett beroende av en tillfällig tjänst kan den tillfälliga tjänsten också kräva trådsäkerhet beroende på hur den används av singletonen.
Fabriksmetoden för en singleton-tjänst, till exempel det andra argumentet till AddSingleton<TService>(IServiceCollection, Func<IServiceProvider,TService>), behöver inte vara trådsäker. Precis som en typkonstruktor (static) kommer den garanterat bara att anropas en gång av en enda tråd.
async/await och Task-baserad tjänstlösning stöds inte. Eftersom C# inte stöder asynkrona konstruktorer använder du asynkrona metoder när tjänsten har lösts synkront.BuildServiceProvider sker vanligtvis när utvecklaren vill återlösa en tjänst vid registreringen av en annan tjänst. Använd i stället en överlagring som innehåller IServiceProvider av den anledningen.Precis som med alla uppsättningar med rekommendationer kan det uppstå situationer där det krävs att du ignorerar en rekommendation. Undantag är sällsynta, mestadels specialfall inom själva ramverket.
DI är ett alternativ till åtkomstmönster för statiska/globala objekt. Du kanske inte kan dra nytta av fördelarna med DI om du blandar det med statisk objektåtkomst.
Förutom riktlinjerna i den här artikeln finns det flera antimönster som du bör undvika. Några av dessa antimönster är lärdomar i utvecklingen av körmiljöerna.
Varning
Det här är exempel på antimönster, kopiera inte koden, använd inte dessa mönster och undvik dessa mönster till varje pris.
När du registrerar tillfälliga tjänster som implementerar IDisposablekommer DI-containern som standard att lagra dessa referenser och inte Dispose() på dem förrän containern tas bort när programmet stoppas om de har lösts från containern eller tills omfånget tas bort om de har lösts från ett omfång. Det kan leda till en minnesläcka om det löses på containernivå.
I föregående antimönster instansieras och rotas 1 000 ExampleDisposable objekt. De tas inte bort förrän instansen serviceProvider tas bort.
Mer information om felsökning av minnesläckor finns i Felsöka en minnesläcka i .NET.
Termen "DI-fabriker" hänvisar till de överlagringsmetoder som finns när du kallar på Add{LIFETIME}. Det finns överlagringar som accepterar en Func<IServiceProvider, T>, där T är tjänsten som registreras, och parametern heter implementationFactory.
implementationFactory Kan anges som ett lambda-uttryck, en lokal funktion eller en metod. Om fabriken är asynkron och du använder Task<TResult>.Resultorsakar detta ett dödläge.
I den föregående koden tilldelas implementationFactory ett lambda-uttryck där kroppen anropar Task<TResult>.Result på en metod som returnerar Task<Bar>. Detta orsakar ett dödläge. Metoden GetBarAsync emulerar helt enkelt en asynkron arbetsåtgärd med Task.Delayoch anropar GetRequiredService<T>(IServiceProvider)sedan .
Mer information om asynkron vägledning finns i Asynkron programmering: Viktig information och råd. Mer information om felsökning av dödlägen finns i Felsöka ett dödläge i .NET.
När du kör det här antimönstret och dödläget inträffar kan du visa de två trådarna som väntar från Parallel Stacks window i Visual Studio. För mer information, se Visa trådar och aktiviteter i fönstret Parallella staplar.
Termen "captive dependency" myntades av Mark Seemann och avser en felkonfiguration av tjänsternas livslängder, där en tjänst med längre livslängd är beroende av en med kortare livslängd.
I föregående kod Foo registreras som en singleton och Bar är begränsad – vilket på ytan verkar giltigt. Tänk dock på implementeringen av Foo.
namespace DependencyInjection.AntiPatterns;
public class Foo(Bar bar)
{
}
Objektet Foo kräver ett Bar objekt, och eftersom Foo är en singleton och Bar är begränsad – det här är en felkonfiguration. Som det är skulle Foo bara instansieras en gång, och det skulle hålla fast Bar under sin livslängd, vilket är längre än den avsedda begränsade livslängden för Bar. Du bör överväga att verifiera omfång genom att skicka validateScopes: true till BuildServiceProvider(IServiceCollection, Boolean). När du validerar rättighetsomfången får du ett InvalidOperationException med ett meddelande som liknar "Det går inte att använda begränsad tjänst 'Bar' från singletonen 'Foo'.".
Mer information finns i Omfångsverifiering.
När du använder begränsade tjänster och inte skapar ett omfång eller befinner dig inom ett befintligt omfång, blir tjänsten en singleton.
I föregående kod Bar hämtas inom en IServiceScope, vilket är korrekt. Antimönstret är hämtningen av Bar utanför omfånget och variabeln namnges avoid för att visa vilket exempel på hämtning som är felaktigt.
Feedback om .NET
.NET är ett öppen källkod projekt. Välj en länk för att ge feedback:
Utbildning
Modul
Konfigurera tjänster med beroendeinmatning i ASP.NET Core - Training
Förstå och implementera beroendeinmatning i en ASP.NET Core-app. Använd ASP.NET Cores inbyggda tjänstcontainer för att hantera beroenden. Registrera tjänster med tjänstcontainern.
Dokumentation
Använd beroendeinjektion - .NET
Lär dig hur du använder beroendeinjektion i dina .NET-appar med denna omfattande handledning. Följ med i den här pragmatiska guiden för att förstå DI i C#.
Lär dig hur du använder beroendeinmatning i dina .NET-appar. Upptäck hur du registrerar tjänster, definierar tjänstlivslängder och expressberoenden i C#.
Grunderna för beroendeinjektion - .NET
Lär dig hur du använder beroendeinmatning (DI) i dina .NET-appar med det här enkla exemplet. Följ med i den här pragmatiska guiden för att förstå GRUNDerna för DI i C#.
