.NET-Konventionen für Dependency Injection: Lifetimes, Scopes und die Captive-Dependency-Falle

Worum es geht

Die .NET-Dokumentation beschreibt einen eingebauten Container: Dienste werden beim Start zu einer IServiceCollection hinzugefügt (AddTransient, AddScoped, AddSingleton oder Keyed-Varianten), BuildServiceProvider oder der generische Host erzeugt den IServiceProvider, und Konsumenten erhalten Abhängigkeiten über einen öffentlichen Konstruktor. Transient-Dienste werden bei jeder Anfrage neu erzeugt; scoped-Dienste einmal pro Scope, in ASP.NET Core also pro Request; Singletons einmal für die Lebensdauer des Containers. Der Container entsorgt, was er erzeugt hat: transient- und scoped-Instanzen am Ende ihres Scopes, Singletons beim Herunterfahren. Hat ein Typ mehrere Konstruktoren, wird derjenige mit den meisten per DI auflösbaren Parametern gewählt, und Mehrdeutigkeit löst einen Fehler aus.

Warum es wichtig ist

Wer von Spring (dort standardmässig singleton) oder von Frameworks ohne Container kommt, neigt dazu, alles als Singleton zu registrieren oder Dienste von Hand aufzulösen. Die Leitlinien-Seite nennt den daraus entstehenden Fehler eine Captive Dependency: Ein länger lebender Dienst hält einen kürzer lebenden fest, sodass ein «pro Request» gedachter DbContext, der von einem Singleton eingefangen wird, stillschweigend von jedem Request geteilt wird. Die Seite zu den Lifetimes hält fest, dass ein scoped-Dienst nicht aus einem Singleton heraus aufgelöst werden darf, weder per Konstruktorinjektion noch über IServiceProvider; die dokumentierte Lösung besteht darin, mit IServiceScopeFactory einen expliziten Scope zu erzeugen.

So wird es angewendet

• Standardmässig transient für zustandslose Dienste, scoped für Zustand pro Request (DbContext, Unit of Work), singleton nur für geteilten, thread-sicheren, teuren Zustand; die Leitlinien verlangen, dass Singletons thread-sicher sind, und warnen vor Kopplung und Speicherverbrauch.
• In Konstruktoren von Schnittstellen abhängen und Konstruktoren frei von Arbeit halten, die über Zuweisungen hinausgeht.
• Nie Dispose an einem injizierten Dienst aufrufen und IDisposable-Typen nicht als transient registrieren, wenn sie aus dem Root-Provider aufgelöst werden könnten; die Leitlinien besagen, dass solche Instanzen bis zur Entsorgung des Containers gehalten werden.
• BuildServiceProvider nicht während der Konfiguration der Dienste aufrufen und GetService nicht als Service Locator verwenden; beides wird als Anti-Pattern geführt.
• Die Scope-Validierung aktiviert lassen: Der Entwicklungs-Host prüft, dass scoped-Dienste weder aus dem Root aufgelöst noch in Singletons injiziert werden, und validateScopes: true bei BuildServiceProvider tut andernorts dasselbe.
• In gehosteten Diensten oder Hintergrunddiensten IServiceScopeFactory injizieren und pro Arbeitseinheit einen Scope erzeugen.

Stolpersteine

Statischer Zugriff auf den Provider (ein eingefangenes ApplicationServices) wird als zu vermeiden geführt: Die Leitlinien besagen, dass die Vorteile von DI verloren gehen, wenn es mit statischem Objektzugriff vermischt wird. Konfiguration oder Nutzerdaten im Container zu speichern, statt das Options-Pattern zu verwenden. Keyed-Dienste brauchen [FromKeyedServices("key")] am Parameter. Einen Dienst zweimal zu registrieren, ist zulässig und leicht zu übersehen.