AddTransient, AddScoped, AddSingleton: Unterschiede in C# mit Beispielen

AddTransient, AddScoped und AddSingleton: So behalten Sie den Überblick über Service-Lebenszyklen in C#

Haben Sie sich schon einmal gefragt: „Warum speichert mein Service Daten zwischen Anfragen, obwohl ich das nicht wollte?“ Oder das Gegenteil: „Warum wird jedes Mal ein neues Objekt erstellt und ich verliere den Zustand?“

Willkommen in der Welt der Dependency Injection (DI) in ASP.NET Core! Dies ist eines der mächtigsten, aber für Einsteiger auch verwirrendsten Konzepte. Heute beleuchten wir die drei Säulen der Objektverwaltung in C#: AddTransient, AddScoped und AddSingleton.

Am Ende dieses Artikels verstehen Sie nicht nur die Unterschiede, sondern können auch souverän in Vorstellungsgesprächen antworten (ja, diese Frage wird gerne gestellt!). Los geht's!

Was ist ein Service-Lebenszyklus und warum braucht man ihn?

Stellen Sie sich Ihre Anwendung wie ein Restaurant vor. Services sind die Köche, Kellner und das Geschirr. Der Lebenszyklus bestimmt, wie lange sie „leben“:

\n
• Transient – ein Einweg-Mitarbeiter. Kommt, kocht eine Portion Suppe und geht. Neue Bestellung – neuer Mitarbeiter.
\n
• Scoped – ein Mitarbeiter für eine Schicht. Bedient alle Kunden, solange das Restaurant geöffnet ist (während einer HTTP-Anfrage).
\n
• Singleton – der Chefkoch, der die gesamte Lebensdauer des Restaurants arbeitet. Einzige Instanz für die ganze Anwendung.
\n

In C# wird diese Logik durch den integrierten DI-Container umgesetzt. Schauen wir uns den Code an.

1. AddTransient – jedes Mal eine neue Instanz

Wann verwenden: Leichte, zustandslose Services (stateless), die keine Daten zwischen Aufrufen speichern. Ideal für Repositories, Helfer und Hilfsprogramme.

Funktionsweise: Jedes Mal, wenn Sie den Service anfordern (über den Konstruktor oder direkt aus dem Container), wird ein neues Objekt erstellt.

// Registrierung in Program.cs\nbuilder.Services.AddTransient<IMyService, MyService>();\n\n// Beispiel-Service\npublic interface IMyService\n{\n    Guid GetInstanceId();\n}\n\npublic class MyService : IMyService\n{\n    private readonly Guid _id = Guid.NewGuid();\n    public Guid GetInstanceId() => _id;\n}\n\n// Controller, der den Service nutzt\npublic class HomeController : Controller\n{\n    private readonly IMyService _service1;\n    private readonly IMyService _service2;\n\n    public HomeController(IMyService service1, IMyService service2)\n    {\n        _service1 = service1;\n        _service2 = service2;\n    }\n\n    public IActionResult Index()\n    {\n        ViewBag.Id1 = _service1.GetInstanceId();\n        ViewBag.Id2 = _service2.GetInstanceId();\n        // Id1 und Id2 sind UNTERSCHIEDLICHE GUIDs!\n        return View();\n    }\n}\n

Wichtig: Selbst innerhalb einer einzigen HTTP-Anfrage erhalten Sie zwei verschiedene Objekte, wenn Sie IMyService an zwei verschiedenen Stellen injizieren. Der Speicherverbrauch ist höher, aber es besteht keine Gefahr von Datenkonflikten.

2. AddScoped – eine Instanz pro Anfrage

Wann verwenden: Services, die innerhalb einer HTTP-Anfrage konsistent sein müssen. Zum Beispiel DbContext in Entity Framework Core, Warenkorb-Services oder Anfragen-Logger.

Funktionsweise: Innerhalb einer HTTP-Anfrage (oder eines Scopes) wird eine einzige Instanz erstellt. Wenn Sie sie mehrmals anfordern, erhalten Sie dasselbe Objekt. Jede neue Anfrage eines anderen Benutzers bekommt jedoch eine eigene Instanz.

// Registrierung\nbuilder.Services.AddScoped<IScopedService, ScopedService>();\n\npublic interface IScopedService\n{\n    Guid GetInstanceId();\n}\n\npublic class ScopedService : IScopedService\n{\n    private readonly Guid _id = Guid.NewGuid();\n    public Guid GetInstanceId() => _id;\n}\n\n// Im selben Controller\npublic