نطاق جلسة Autofac

Question

أقوم بالتحقيق في استخدام Autofac في تطبيق الويب الخاص بنا بعد أن استخدمت Castle Windsor سابقًا في الماضي.

الشيء الذي يعجبني حقًا في Autofac هو القدرة على التعبير عن بناء المكونات الديناميكية من خلال تعبيرات lamda، بدلاً من إنشاء DependancyResolvers وما إلى ذلك.في وندسور.

أحد السيناريوهات لدي هو أنني أريد تسجيل مكون معين في نطاق مستوى جلسة ASP.NET.مع Windsor، سأقوم بإنشاء/مصدر LifestyleManager جديد، ولكن مع Autofac توصلت إلى ما يلي:

//Register SessionContext at HTTP Session Level
builder.Register(c =>
{
    HttpContext current = HttpContext.Current;

    //HttpContext handes delivering the correct session
    Pelagon.Violet.Core.Interfaces.SessionContext instance = current.Session["SessionContext"] as Pelagon.Violet.Core.Interfaces.SessionContext;

    if (instance == null)
    {
        instance = c.Resolve<Pelagon.Violet.Core.Interfaces.SessionContext>();
        current.Session["SessionContext"] = instance;
    }

    return instance;
})
.FactoryScoped();

والتي في مرحلة ما قد أتمكن من تحويلها إلى طريقة تمديد.أوافق على أن هذا التنفيذ سيتم تفجيره إذا كانت جلسة HttpContext.Current.Session فارغة حيث يجب استخدامها فقط في تطبيق الويب.

السؤال هو:

ما هي أفضل الممارسات لمثل هذا التسجيل في Autofac.لقد رأيت الكثير من الإشارات حول استخدام الحاويات المتداخلة وما إلى ذلك.لكن لا توجد أمثلة ملموسة، وأنا حريص على فهم ما قد يكون خطأ في النهج المذكور أعلاه (الشيء الوحيد الذي يمكنني التفكير فيه هو عناصر التخلص التلقائي).

شكرًا.

Answer 1

هذا يبدو جيدا.

سيؤدي وضع علامة على المكون "ExternallyOwned()" إلى ضمان عدم استدعاء Autofac Dispose() عليه.

المشكلة الوحيدة هنا هي أن المكون الخاص بنطاق الجلسة يمكنه حل التبعيات الخاصة به عبر الحاوية الحالية، وبالتالي يحتفظ بمراجع إلى الأشياء التي قد تنتمي إلى الطلب الحالي (على سبيل المثال.) ومع ذلك، يجب أن يكون من السهل اكتشاف ذلك أثناء الاختبار.