როგორ მუშაობს dependency injection .NET-ში?

Question

Accepted Answer

**Dependency Injection (DI)** ჩაშენებულია თანამედროვე .NET-ში — ფреიმვორკი მოიცავს DI კონტეინერს, რომელიც ავტომატურად აკonstruкტებს კლასებს და **ინჯექტებს მათ დამოკიდებულებებს**. თქვენ ცდილობთ სერვისებს (ინტერფეისების შედაბამებას იმპლემენტაციებთან) და კონტეინერი მათ გადაჭრის, რაც სუსტი შეკავშირება და ტესტირებადი კოდის შესაძლებლობას იძლევა. ეს საფუძველია ASP.NET Core-ისთვის. ## სერვისების რეგისტრაცია ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` თქვენ ცდილობთ თითოეულ სერვისის შედაბამებას **ინტერფეისიდან იმპლემენტაციამდე** lifetime-ით. შემდეგ, ყველაფერი, რაც დამოკიდებულია ინტერფეისზე, იღებს დარეგისტრირებულ იმპლემენტაციას. ## კონსტრუქტორის ინჯექცია (სტანდარტული ნიმუში) ```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 ``` დამოკიდებულებები დეკლარირებულია კონსტრუქტორის პარამეტრებად (აკრეფილი ინტერფეისებად); კონტეინერი აკonstruкტებს კლასს და ინჯექტებს დარეგისტრირებულ იმპლემენტაციებს, ავტომატურად გადაჭრის მთელ დამოკიდებულების გრაფიკს. ## სერვისის lifetime-ები (მნიშვნელოვანია სწორი ასარჩევად) ```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. ``` ## სარგებელი: სუსტი შეკავშირება და ტესტირებადობა ```csharp // because UserService depends on INTERFACES, you can inject MOCKS in tests var service = new UserService(mockRepo, mockEmail); // no real DB/email needed ``` ## რატომ აქვს მნიშვნელობა დependency injection თანამედროვე .NET-ის საფუძველია — ეს **ჩაშენებულია ფреიმვორკში** და არის ASP.NET Core-ის ხერხემლი, ამიტომ მის გაგება აუცილებელია ნებისმიერი თანამედროვე C# აპლიკაციის განვითარებისთვის. ფреიმვორკის ჩაშენებული DI კონტეინერი ავტომატურად აკonstruკტებს კლასებს და ინჯექტებს მათ დამოკიდებულებებს (ხსნის მთელ დამოკიდებულების გრაფიკს), ამიტომ თქვენ ცდილობთ სერვისებს და აძლევთ კონტეინერს მთელი რამ ერთად აკმაყოფილოს, ნაცვლად მანუალური დამოკიდებულების ინსტანცირების. ძირითადი სარგებელი მნიშვნელოვანი და ცენტრალური, თუ რატომ ხაზგასმაა DI: **სუსტი შეკავშირება** (დამოკიდებული ინტერფეისებზე და არა კონკრეტული კლასებზე, ამიტომ იმპლემენტაციები შეიძლება გაკეცილი იყოს) და განსაკუთრებით **ტესტირებადობა** (მხილველი იმპლემენტაციების ინჯექცია ტესტებში რეალური დამოკიდებულების ნაცვლად, როგორიცაა მონაცემთა ბაზა ან ელ-ფოსტის სერვისები — რაც საფუძველს უქმნის ღრმა ერთეული ტესტირების გაკეთების შესაძლებლობას). სერვისების რეგისტრაციის გაგება (ინტერფეისების შედაბამება იმპლემენტაციებთან), კონსტრუქტორის ინჯექცია (სტანდარტული ნიმუში) და — მნიშვნელოვნად — **სერვისის lifetime-ები** (`Singleton`, `Scoped`, `Transient`) აუცილებელია: არასწორი lifetime არჩევა იწვევს დახვეწილი, რთული აღმოჩენის ხარვეზებს (მაგ. singleton, რომელიც აკავებს scoped `DbContext`-ს, ან thread-safety პრობლემებს გაზიარებული singleton-ებით), ამიტომ იმის გაგება, თუ როდის გამოიყენება თითოეული lifetime (Scoped თითოეული მოთხოვნის მიხედვით რაოდენი `DbContext`-ის მსგავსი, Singleton გაზიარებული stateless სერვისებისთვის, Transient მსუბუქი მოდელებისთვის) კრიტიკულია. ვინაიდან DI ჩაშენებულია .NET-ში, ძირს უწერს ASP.NET Core-ის არქიტექტურას, და არის კლიშე სუსტი შეკავშირება და ტესტირებადი კოდის დაწერის გასაღები, მისტერი — კონტეინერი, კონსტრუქტორის ინჯექცია, ინტერფეისზე დაფუძნებული დიზაინი, და განსაკუთრებით სერვისის lifetime-ები — მნიშვნელოვანი, ხშირად გამოყენებული უფროსი ცოდნა უწინდელი, ტესტირებადი თანამედროვე C# აპლიკაციების აგებისთვის, და ჩვეულებრივი ინტერვიუს თემა.