Jak działa wstrzykiwanie zależności (dependency injection) w .NET?

Question

Accepted Answer

**Dependency Injection (DI)** jest wbudowany w nowoczesny .NET — framework zawiera kontener DI, który automatycznie konstruuje klasy i **wstrzykuje ich zależności**. Rejestrujesz usługi (mapując interfejsy na implementacje), a kontener je rozwiązuje, umożliwiając luźne sprzężenie i testowalny kod. To fundament ASP.NET Core. ## Rejestrowanie usług ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` Rejestrujesz każde mapowanie usługi z **interfejsu na implementację** z określonym czasem życia. Wszystko, co zależy od interfejsu, otrzymuje zarejestrowaną implementację. ## Wstrzykiwanie przez konstruktor (standardowy wzorzec) ```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 ``` Zależności są deklarowane jako parametry konstruktora (typowane jako interfejsy); kontener konstruuje klasę i wstrzykuje zarejestrowane implementacje, automatycznie rozwiązując cały graf zależności. ## Czasy życia usług (ważne, aby wybrać prawidłowo) ```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. ``` ## Korzyści: luźne sprzężenie i testowalność ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## Dlaczego to ważne Wstrzykiwanie zależności jest fundamentem nowoczesnego .NET — jest **wbudowany w framework** i stanowi kostręć ASP.NET Core, więc zrozumienie go jest niezbędne dla każdego programowania nowoczesnych aplikacji w C#. Wbudowany w framework kontener DI automatycznie konstruuje klasy i wstrzykuje ich zależności (rozwiązując cały graf zależności), więc rejestrujesz usługi i pozwalasz kontenerowi połączyć wszystko razem zamiast ręcznie instancjonować zależności. Główne korzyści są znaczące i centralne dla tego, dlaczego DI jest podkreślane: **luźne sprzężenie** (zależy od interfejsów zamiast konkretnych klas, więc implementacje mogą być wymieniane) i szczególnie **testowalność** (wstrzykiwanie implementacji mock w testach zamiast rzeczywistych zależności, takich jak bazy danych lub usługi email — czyniąc gruntowne testowanie jednostkowe praktyczne). Zrozumienie sposobu rejestrowania usług (mapowanie interfejsów na implementacje), wstrzykiwania przez konstruktor (standardowy wzorzec) i — co ważne — **czasów życia usług** (`Singleton`, `Scoped`, `Transient`) jest niezbędne: wybór nieprawidłowego czasu życia powoduje subtelne, trudne do debugowania błędy (np. singleton przechowujący scoped `DbContext`, lub problemy z bezpieczeństwem wątków w współdzielonych singletonach), więc zrozumienie, kiedy każdy czas życia ma zastosowanie (Scoped na żądanie dla rzeczy takich jak DbContext, Singleton dla współdzielonych usług bezstanowych, Transient dla lekkich), jest krytyczne. Ponieważ DI jest wbudowany w .NET, stanowi podstawę architektury ASP.NET Core i jest kluczem do pisania luźno sprzężonego, testowalnego kodu, opanowanie go — kontenera, wstrzykiwania przez konstruktor, projektowania opartego na interfejsach i szczególnie czasów życia usług — to ważna, często stosowana wiedza na poziomie seniora do budowania maintainable, testowalnych nowoczesnych aplikacji w C# i częsty temat rozmów kwalifikacyjnych.