Hur fungerar dependency injection i .NET?

Question

Accepted Answer

**Dependency Injection (DI)** är inbyggt i modern .NET — ramverket innehåller en DI-container som automatiskt konstruerar klasser och **injicerar deras beroenden**. Du registrerar tjänster (mappning av gränssnitt till implementeringar) och containern löser dem, vilket möjliggör löst kopplad, testbar kod. Det är grundläggande för ASP.NET Core. ## Registrera tjänster ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` Du registrerar varje tjänstemappning mellan ett **gränssnitt och en implementering** med en livstid. Då får allt som är beroende av gränssnittet den registrerade implementeringen. ## Konstruktorinjection (standardmönstret) ```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 ``` Beroenden deklareras som konstruktorparametrar (typade som gränssnitt); containern konstruerar klassen och injicerar de registrerade implementeringarna, vilket löser hela beroendegrafen automatiskt. ## Tjänstelivstider (viktigt att välja rätt) ```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. ``` ## Fördelarna: löst koppling och testbarhet ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## Varför det spelar roll Dependency injection är grundläggande för modern .NET — det är **inbyggt i ramverket** och är ryggraden i ASP.NET Core, så att förstå det är väsentligt för all modern C#-utveckling. Ramverkets inbyggda DI-container konstruerar automatiskt klasser och injicerar deras beroenden (löser hela beroendegrafen), så du registrerar tjänster och låter containern koppla ihop allt tillsammans istället för att manuellt instansiera beroenden. Kärnfördelarna är betydande och centrala för varför DI betonas: **löst koppling** (beroende av gränssnitt snarare än betongklasser, så implementeringar kan bytas ut) och särskilt **testbarhet** (injicera mock-implementeringar i tester istället för riktiga beroenden som databaser eller e-posttjänster — vilket gör grundlig enhetstestning praktisk). Att förstå hur man registrerar tjänster (mappning av gränssnitt till implementeringar), konstruktorinjection (standardmönstret) och — viktigt — **tjänstelivstiderna** (`Singleton`, `Scoped`, `Transient`) är väsentligt: att välja fel livstid orsakar subtila, svårfelsökade buggar (t.ex. en singleton som håller en begränsad `DbContext`, eller trådssäkerhetsproblem med delade singletons), så att förstå när varje livstid tillämpas (Scoped per förfrågan för saker som DbContext, Singleton för delade tillståndslösa tjänster, Transient för lätta) är kritiskt. Eftersom DI är inbyggt i .NET, utgör grunden för ASP.NET Cores arkitektur och är nyckeln till att skriva löst kopplad, testbar kod, är det att behärska det — containern, konstruktorinjection, gränssnittsbaserad design och särskilt tjänstelivstiderna — viktigt, ofta använd seniorkompetens för att bygga underhållbar, testbar modern C#-kod, och ett vanligt intervjuämne.