معالجة إخفاقات تسجيل الاعتماديات ونطاقاتها

افهم الأسباب المحتملة

• قد يكون تسجيل الواجهة وتنفيذها غائبًا أو غير متطابق، أو يحتفظ مالك أطول عمرًا بحالة أقصر عمرًا، أو تستمر مهمة بعد التخلّص من نطاقها. وقد يؤدي استدعاء BuildServiceProvider إضافي أثناء التسجيل إلى إنشاء رسم ملكية آخر. لا يثبت نجاح حل الخدمة مرة واحدة صحة مشاركتها أو سلامتها عند التزامن أو تنظيف مواردها.

1. سجّل النوع المطلوب وعمر الخدمة التي تستهلكه

اقرأ أول استثناء ذي صلة، وحدّد نوع الخدمة المطلوبة والجهة التي تستهلكها، وهل يقع الفشل أثناء بناء مزوّد الخدمات أم حل الاعتمادية أم استخدامها لاحقًا. قارن التسجيل الدقيق الذي يتوقعه المنشئ، سواء تعلق بواجهة أو نوع عام أو تسجيل مسمّى. ابدأ برسم اعتماديات اصطناعي صغير، ولا تفحص تطبيق قائم مهيأ أو تعِد تشغيله لمجرد اختبار تخمين.

2. ارسم حدود المشاركة ومسؤولية التخلّص من الموارد

صنّف النسخ ذات العمر singleton أو scoped أو transient، والنسخ التي ينشئها مصنع، وتلك المنشأة مسبقًا، وفق قواعد الحاوية. حدّد من يملك مسؤولية التخلّص من كل كائن، والمدة التي تستخدمه خلالها كل جهة تستعيره. قد تتلقى خدمة scoped استدعاءات متزامنة حتى داخل طلب واحد. أما الاحتفاظ بـHttpContext أو DbContext داخل singleton أو مهمة خلفية فهو عيب تصميم مستقل عن غياب التسجيل.

3. تحقّق من التسجيل المقصود داخل نطاق معزول

يسجّل البرنامج المكتمل واجهة قارئ اصطناعي ويحلّها داخل نطاق صريح يملك موارده، مع تفعيل فحوص مزوّد الخدمات ذات الصلة. يوضح بذلك رسمًا محليًا صحيحًا ونتيجة مفيدة، لكنه لا يفتح قاعدة بيانات ولا يتحقق من بدء مضيف التطبيق أو تنفيذ المستودع الحقيقي. استخدم هذا النمط من الأدلة لعزل رسم الاعتماديات قبل اقتراح تعديل التطبيق.

using System;
using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();
services.AddScoped<IReportReader, SyntheticReader>();
using var provider = services.BuildServiceProvider(new ServiceProviderOptions { ValidateScopes = true, ValidateOnBuild = true });
using var scope = provider.CreateScope();
int result = scope.ServiceProvider.GetRequiredService<IReportReader>().Read();
Console.WriteLine($"read={result}");

internal interface IReportReader { int Read(); }
internal sealed class SyntheticReader : IReportReader { public int Read() => 7; }

read=7

4. امنح العمل طويل العمر نطاقًا محدودًا أو موردًا ينشئه مصنع

إذا احتاج عامل singleton إلى عمل يستخدم خدمات scoped، فأنشئ نطاقًا صالحًا أو موردًا عبر مصنع لوحدة عمل محدودة، وانتظر اكتمال الجهات التي تستخدمه، ثم تخلّص منه. لا تكتفِ بتحويل DbContext إلى singleton أو حلّها من المزوّد الجذري. استخدم سياقات منفصلة للعمليات المتوازية عندما يتطلب تصميم المزوّد ذلك. وحتى بعد طلب الإلغاء، يجب ملاحظة اكتمال العمل قبل تحرير موارده.

5. أزل الملكية المكررة وحلّ الخدمات الخفي

تجنب بناء مزوّد ثانٍ أثناء التسجيل، أو الاحتفاظ بخدمات transient قابلة للتخلّص إلى أجل غير محدود، أو التخلّص داخل أسلوب من اعتماديات تستعيرها من الحاوية. اجمع التسجيلات عند نقطة تركيب الاعتماديات، واجعل الاعتماديات صريحة. وإذا أنشأ مصنع موردًا، فوثّق من يحرره. قد يبقى الحادث محلولًا جزئيًا فقط إذا أُصلح التسجيل وظل حد المهمة اللاحقة والتخلّص من مواردها غير صحيح.

امنع تكرار المشكلة

• احتفظ بمخططات أعمار الخدمات، واعتماديات المنشئات والمعالجات، وفحوص النطاق، واختبارات الملكية. راجع الخدمات الخلفية والمصانع كلما تغيرت الاعتماديات. احرص على اكتمال العمل غير المتزامن قبل التخلّص من موارده، وتجنب اختصارات حلّ الخدمات من الجذر أو من موضع عام. أصلح رسم الاعتماديات المقصود بدل إضعاف الفحوص لكي يبدو بدء التطبيق ناجحًا فقط.