Hogyan működik a dependency injection a .NET-ben?

Question

Accepted Answer

**Dependency Injection (DI)** beépített a modern .NET-be — a keretrendszer tartalmaz egy DI konténert, amely automatikusan felépít osztályokat és **injektálja azok függőségeit**. Regisztrálsz szolgáltatásokat (interfészeket megvalósításokra leképezve), és a konténer feloldja őket, lehetővé téve a lazán csatolt, tesztelhető kódot. Ez az ASP.NET Core alapja. ## Szolgáltatások regisztrálása ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` Minden szolgáltatás-leképezést regisztrálsz egy **interfész és egy megvalósítás** közötti kapcsolattal egy élettartammal. Ezt követően bármi, ami az interfész-től függ, megkapja a regisztrált megvalósítást. ## Konstruktor injekció (a standard minta) ```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 ``` A függőségek konstruktor paramétereiként vannak deklarálva (interfészekként tipizálva); a konténer felépíti az osztályt és injektálja a regisztrált megvalósításokat, automatikusan feloldva az egész függőségi gráfot. ## Szolgáltatás élettartamok (fontos a helyes megválasztás) ```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. ``` ## Az előnyök: laza csatolás és tesztelhetőség ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## Miért fontos A dependency injection alapvető a modern .NET-ben — **beépített a keretrendszerbe** és az ASP.NET Core gerince, így a megértése alapvető bármely modern C# alkalmazásfejlesztéshez. A keretrendszer beépített DI konténere automatikusan felépíti az osztályokat és injektálja azok függőségeit (feloldva az egész függőségi gráfot), így regisztrálsz szolgáltatásokat, és hagyod, hogy a konténer összekösse az egészet, ahelyett, hogy manuálisan példányosítanál függőségeket. A fő előnyök jelentősek és központiak abban, hogy miért hangsúlyoznak DI-t: **laza csatolás** (interfészektől függés, nem konkrét osztályoktól, így a megvalósítások cserélhetőek), és különösen **tesztelhetőség** (hamis megvalósítások injektálása tesztekben valós függőségek helyett, mint adatbázisok vagy e-mail szolgáltatások — gyakorlatilagá teszi a alapos egység tesztelést). Annak megértése, hogyan regisztrálsz szolgáltatásokat (interfészeket leképezve megvalósításokra), konstruktor injekció (a standard minta), és — fontos — a **szolgáltatás élettartamok** (`Singleton`, `Scoped`, `Transient`) elengedhetetlen: a rossz élettartam megválasztása finom, nehezen felderíthető hibákat okoz (pl. egy singleton, amely tartalmaz egy scoped `DbContext`-et, vagy szálbiztonsági problémák megosztott singletonok esetén), így annak megértése, hogy mikor mit alkalmazz (Scoped kérésenkénti dolgokhoz, mint DbContext, Singleton megosztott állapot nélküli szolgáltatásokhoz, Transient könnyű súlyúakhoz) kritikus. Mivel a DI beépített a .NET-be, az ASP.NET Core architektúrájának gerince, és a kulcsa a lazán csatolt, tesztelhető kód írásának, a megértése — a konténer, konstruktor injekció, interfész alapú tervezés, és különösen a szolgáltatás élettartamok — fontos, gyakran alkalmazott senior tudás a karbantartható, tesztelhető modern C# alkalmazások építéséhez, és egy gyakori interjúkérdés.