Miten riippuvuuksien injektointi toimii .NET-kehyksessä?

Question

IT Interview Practice · Accepted Answer

**Riippuvuuksien injektointi (DI)** on rakennettu moderniin .NET-kehykseen — kehys sisältää DI-säiliön, joka automaattisesti konstruoi luokkia ja **injektoi niiden riippuvuudet**. Rekisteröit palvelut (mappaat rajapinnat toteutuksiin) ja säiliö ratkaisee ne, mahdollistaen löyhästi kytketyn, testattavan koodin. Se on ASP.NET Core:n perusrakennus. ## Palveluiden rekisteröiminen ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` Rekisteröit jokaisen palvelun mappaamalla **rajapinnan toteutukseen** elinkaaren kanssa. Sitten mitä tahansa rajapintaan riippuvaista saa rekisteröidyn toteutuksen. ## Konstruktorin injektointi (vakiomuotoinen kuvio) ```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 ``` Riippuvuudet ilmoitetaan konstruktorin parametreina (tyypitettynä rajapintoina); säiliö konstruoi luokan ja injektoi rekisteröidyt toteutukset, ratkoen koko riippuvuusgraafin automaattisesti. ## Palveluiden elinkaaret (tärkeä valita oikein) ```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. ``` ## Hyödyt: löyhä kytkentä ja testattavuus ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## Miksi se on tärkeää Riippuvuuksien injektointi on modernin .NET-kehyksen perusta — se on **rakennettu kehykseen** ja muodostaa ASP.NET Core:n selkärangan, joten sen ymmärtäminen on välttämätöntä missä tahansa modernissa C#-sovelluskehityksessä. Kehyksen sisäänrakennettu DI-säiliö automaattisesti konstruoi luokkia ja injektoi niiden riippuvuudet (ratkoen koko riippuvuusgraafin), joten rekisteröit palvelut ja annat säiliön yhdistää kaikki yhteen manuaalisen instansoinnin sijaan. Ydinedut ovat merkittävät ja keskeisiä sille, miksi DI on korostettua: **löyhä kytkentä** (riippuvuus rajapintoihin eikä konkreettisiin luokkiin, joten toteutukset voidaan vaihtaa) ja erityisesti **testattavuus** (mock-toteutusten injektoiminen testeihin oikeiden riippuvuuksien (kuten tietokantojen tai sähköpostipalvelujen) sijaan — tekemällä perusteellisen yksikkötestaamisen käytännölliseksi). Ymmärtää, kuinka rekisteröidä palvelut (rajapintojen mappaaminen toteutuksiin), konstruktorin injektointi (vakiomuotoinen kuvio) ja — tärkeää — **palveluiden elinkaaret** (`Singleton`, `Scoped`, `Transient`), on välttämätöntä: väärän elinkaaren valitseminen aiheuttaa subtiilejä, vaikea-löydettäviä bugeja (esim. singleton, joka säilyttää scoped `DbContext`:ia, tai säikeensisäisiä turvallisuusongelmia jaetuissa singletonissa), joten ymmärtää, milloin kutakin elinkaarta käytetään (Scoped pyyntöä kohden asioille kuten DbContext, Singleton yhteisille tilattomille palveluille, Transient kevyille) on kriittistä. Koska DI on rakennettu .NET:iin, muodostaa ASP.NET Core:n arkkitehtuurin perustan ja on avain löyhästi kytketyn, testattavan koodin kirjoittamiseen, sen hallitseminen — säiliö, konstruktorin injektointi, rajapintoihin perustuva suunnittelu ja erityisesti palveluiden elinkaaret — on tärkeä, usein sovellettu senioritason tietämys ylläpidettävien, testattavien modernien C#-sovellusten rakentamiselle, ja yleinen haastattelukysymys.

Palveluiden rekisteröiminen

Konstruktorin injektointi (vakiomuotoinen kuvio)

Palveluiden elinkaaret (tärkeä valita oikein)

Hyödyt: löyhä kytkentä ja testattavuus

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset