💡 1. Interfaces & Service Lifetimes in .NET
Klassen fordern ihre Abhängigkeiten im Konstruktor an (Inversion of Control). Der .NET DI-Container kümmert sich um die Erzeugung und Lebenszeit:
public interface INotificationService {
Task SendAsync(string recipient, string message);
}
public class EmailNotificationService : INotificationService {
public async Task SendAsync(string recipient, string message) {
Console.WriteLine($"[Email an {recipient}]: {message}");
await Task.CompletedTask;
}
}
// Service, der über DI entkoppelt ist:
public class OrderService(INotificationService notifier) {
public async Task CompleteOrderAsync(int orderId, string customerEmail) {
// ... Bestellogik ...
await notifier.SendAsync(customerEmail, $"Bestellung {orderId} bestätigt!");
}
}
Ein USB-C-Kabel fragt nicht, ob am anderen Ende ein Samsung, Apple oder eine Festplatte hängt. Das Interface garantiert die Buchse – die konkrete Implementierung steckst du zur Laufzeit ein!
⚡ 2. Quick-Cheat-Sheet
| DI Lifetime | Methode | Wann wird instanziiert? |
|---|---|---|
| Transient | AddTransient() | Jedes Mal neu, wenn angefordert (flüchtig) |
| Scoped | AddScoped() | Einmal pro Web-Request / Scope (Standard in Web-APIs) |
| Singleton | AddSingleton() | Genau einmal für die gesamte Anwendungslebensdauer |
⚠️ 3. Häufige Stolperfallen (Gotchas & Anti-Patterns)
Registriert man einen Singleton-Service, der einen Scoped-Service im Konstruktor injiziert, wird der Scoped-Service fälschlicherweise zum Singleton eingefroren!
Schreibt man im Service var repo = new SqlRepository();, hebelt man Dependency Injection aus und macht Unit-Testing unmöglich.
🧠 4. Diagnostischer Selbst-Check
Überprüfe dein Verständnis von Sprach-Features, Speicherverwaltung und Enterprise-Architektur, bevor du den Code in der Web-IDE schreibst.