كيف يعمل حقن الاعتماديات (Dependency Injection) في .NET؟

Question

Accepted Answer

**حقن الاعتماديات (Dependency Injection - DI)** مدمجة في .NET الحديث — الإطار يتضمن حاوية DI تقوم تلقائياً ببناء الفئات و**حقن اعتماديتها**. تقوم بتسجيل الخدمات (ربط الواجهات بالتطبيقات) والحاوية تقوم بحلها، مما يتيح كوداً فضفاضاً والاقتران وقابلاً للاختبار. إنها أساسية لـ ASP.NET Core. ## تسجيل الخدمات ```csharp // in Program.cs — register services with a LIFETIME builder.Services.AddScoped(); // interface → implementation builder.Services.AddSingleton(); builder.Services.AddTransient(); ``` تقوم بتسجيل كل تعيين خدمة يربط **واجهة بتطبيق** مع عمر زمني. ثم أي شيء يعتمد على الواجهة يحصل على التطبيق المسجل. ## حقن البناء (Constructor Injection) — النمط القياسي ```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 ``` يتم التصريح عن الاعتماديات كمعاملات بناء (من نوع الواجهات)؛ الحاوية تقوم بإنشاء الفئة وحقن التطبيقات المسجلة، وحل رسم الاعتمادية بالكامل تلقائياً. ## أعمار الخدمة (مهم اختيارها بشكل صحيح) ```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 ``` ## لماذا يهم حقن الاعتماديات أساسية لـ .NET الحديث — إنها **مدمجة في الإطار** وهي العمود الفقري لـ ASP.NET Core، لذا فهم هذا المفهوم ضروري لأي تطوير تطبيقات C# حديثة. حاوية DI المدمجة في الإطار تقوم تلقائياً ببناء الفئات وحقن اعتماديتها (حل رسم الاعتمادية بالكامل)، لذا تقوم بتسجيل الخدمات ودع الحاوية توصل كل شيء معاً بدلاً من الإنشاء اليدوي للاعتماديات. الفوائد الأساسية كبيرة وأساسية لماذا يتم التركيز على DI: **الفصل الفضفاض** (الاعتماد على الواجهات بدلاً من الفئات الملموسة، بحيث يمكن تبديل التطبيقات) وخاصة **قابلية الاختبار** (حقن التطبيقات الوهمية في الاختبارات بدلاً من الاعتماديات الحقيقية مثل قواعد البيانات أو خدمات البريد الإلكتروني — مما يجعل اختبار الوحدة الشامل عملياً). فهم كيفية تسجيل الخدمات (ربط الواجهات بالتطبيقات)، وحقن البناء (النمط القياسي)، و — بشكل مهم — **أعمار الخدمة** (`Singleton`، `Scoped`، `Transient`) ضروري: اختيار العمر الخاطئ يسبب أخطاء دقيقة وصعبة في التصحيح (مثلاً singleton يحمل `DbContext` محدود النطاق، أو مشاكل أمان الخيوط مع singletons مشتركة)، لذا فهم متى ينطبق كل عمر (Scoped لكل طلب للأشياء مثل DbContext، Singleton للخدمات المشتركة التي لا تحافظ على حالة، Transient للخدمات الخفيفة) حرج. بما أن DI مدمجة في .NET، وتدعم معمارية ASP.NET Core، وهي المفتاح لكتابة كود فضفاض الاقتران وقابل للاختبار، إتقان هذا المفهوم — الحاوية، وحقن البناء، والتصميم القائم على الواجهات، وخاصة أعمار الخدمة — مهم، ومعرفة متقدمة تُطبق بشكل متكرر لبناء تطبيقات C# حديثة قابلة للصيانة واختبار شامل، وموضوع مقابلة شائع.