Hvordan fungerer avhengigheetsinjeksjon i .NET?

Question

Accepted Answer

**Dependency Injection (DI)** er innebygd i moderne .NET — rammeverket inkluderer en DI-container som automatisk konstruerer klasser og **injiserer deres avhengigheter**. Du registrerer tjenester (kartlegger grensesnitt til implementeringer) og containeren løser dem, noe som muliggjør løst koblet, testbar kode. Det er grunnleggende for ASP.NET Core. ## Registrering av tjenester ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` Du registrerer hver tjeneste ved å kartlegge et **grensesnitt til en implementering** med en levetid. Deretter får alt som avhenger av grensesnittet den registrerte implementeringen. ## Konstruktørinjeksjon (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 ``` Avhengigheter er deklarert som konstruktørparametere (skrevet som grensesnitt); containeren konstruerer klassen og injiserer de registrerte implementeringene, og løser hele avhengighetsgrafien automatisk. ## Tjenestens levetider (viktig å velge riktig) ```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 koblet og testbarhet ```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 er viktig Avhengigheetsinjeksjon er grunnleggende for moderne .NET — det er **innebygd i rammeverket** og er ryggraden i ASP.NET Core, så å forstå det er essensielt for all moderne C#-applikasjoneutvikling. Rammeverkets innebygde DI-container konstruerer automatisk klasser og injiserer deres avhengigheter (løser hele avhengighetsgrafien), så du registrerer tjenester og lar containeren koble alt sammen i stedet for å manuelt instansiere avhengigheter. Kjernfordelene er betydelige og sentrale for hvorfor DI blir vektlagt: **løs koblet** (avhenger av grensesnitt i stedet for konkrete klasser, slik at implementeringer kan byttes ut) og spesielt **testbarhet** (injiserer mock-implementeringer i tester i stedet for ekte avhengigheter som databaser eller e-posttjenester — noe som gjør grundig enhetstesting praktisk). Å forstå hvordan man registrerer tjenester (kartlegger grensesnitt til implementeringer), konstruktørinjeksjon (standardmønsteret) og — viktig — **tjenestelevetidene** (`Singleton`, `Scoped`, `Transient`) er essensielt: å velge feil levetid forårsaker subtile, vanskelig debuggbare feil (f.eks. en singleton som holder en scoped `DbContext`, eller trådikkehet-problemer med delte singletons), så å forstå når hver levetid gjelder (Scoped per-forespørsel for ting som DbContext, Singleton for delte tilstandsløse tjenester, Transient for lette) er kritisk. Fordi DI er innebygd i .NET, underbygger ASP.NET Core-arkitektur og er nøkkelen til å skrive løst koblet, testbar kode, er det viktig å mestre det — containeren, konstruktørinjeksjon, grensesnittbasert design og spesielt tjenestelevetidene — er viktig, ofte brukt seniorviten for å bygge vedlikeholdbar, testbar moderne C#-applikasjoner, og et vanlig intervjuemne.