Hvordan fungerer dependency injection i .NET?

Question

Accepted Answer

**Dependency Injection (DI)** er indbygget i moderne .NET — frameworket inkluderer en DI-container, der automatisk konstruerer klasser og **injicerer deres dependencies**. Du registrerer services (kortlægger interfaces til implementeringer), og containeren løser dem, hvilket muliggør løst koblet, testbar kode. Det er grundlæggende for ASP.NET Core. ## Registrering af services ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` Du registrerer hver service-kortlægning af et **interface til en implementering** med en livstid. Derefter får alt, der afhænger af interfacet, den registrerede implementering. ## Constructor injection (standardmønsteret) ```csharp public class UserService { private readonly IUserRepository _repo; private readonly IEmailSender _email; // dependencies are declared in the constructor — the container INJECTS them automatically public UserService(IUserRepository repo, IEmailSender email) { _repo = repo; _email = email; } } // you never `new UserService(...)` manually — the container builds it, resolving the chain ``` Dependencies er erklæret som constructor-parametre (indtastet som interfaces); containeren konstruerer klassen og injicerer de registrerede implementeringer, hvilket automatisk løser hele dependency graph. ## Service lifetimes (vigtigt at vælge korrekt) ```text Singleton → ONE instance for the entire app lifetime (shared; must be thread-safe) Scoped → one instance PER request (the common default for web — e.g. DbContext) Transient → a NEW instance every time it's requested (lightweight, stateless services) → Choosing wrong (e.g. a singleton capturing a scoped DbContext) causes subtle bugs. ``` ## Fordelene: løs kobling og testbarhed ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## Hvorfor det betyder noget Dependency injection er grundlæggende for moderne .NET — det er **indbygget i frameworket** og er rygraden i ASP.NET Core, så det at forstå det er væsentligt for enhver moderne C#-applikationsudvikling. Frameworkets indbyggede DI-container konstruerer automatisk klasser og injicerer deres dependencies (løser hele dependency graph), så du registrerer services og lader containeren samle alt sammen i stedet for manuelt at instantiere dependencies. De vigtigste fordele er betydelige og centrale for, hvorfor DI lægges vægt på: **løs kobling** (afhængigt af interfaces frem for konkrete klasser, så implementeringer kan byttes ud) og især **testbarhed** (injicering af mock-implementeringer i tests i stedet for rigtige dependencies som databaser eller email-services — hvilket gør grundig enhedstest praktisk). At forstå, hvordan man registrerer services (kortlægger interfaces til implementeringer), constructor injection (standardmønsteret), og — vigtigst — **service lifetimes** (`Singleton`, `Scoped`, `Transient`) er væsentligt: at vælge forkert livstid forårsager subtile, svært at debugge fejl (f.eks. en singleton, der holder en scoped `DbContext`, eller thread-safety-problemer med delte singletons), så at forstå, hvornår hver livstid gælder (Scoped pr. anmodning for ting som DbContext, Singleton for delte stateless-services, Transient for lette), er kritisk. Da DI er indbygget i .NET, understøtter ASP.NET Cores arkitektur, og er nøglen til at skrive løst koblet, testbar kode, er det at mestre det — containeren, constructor injection, interface-baseret design, og især service lifetimes — vigtig, hyppigt anvendt senior-viden til at bygge vedligeholdelig, testbar moderne C#-applikationer, og er et almindeligt interviewemne.