‫چالش‌های الگوی Service Locator و پیاده‌سازی Scoped Interceptors در EF Core

• هم‌راستایی محدوده (Scope Alignment): محیط HttpContext.RequestServices به طور مستقیم به کانتینر Scoped ایجاد شده برای آن درخواست HTTP خاص اشاره دارد.
• تطابق طول عمر (Lifetime Match): هر سرویسی که از این طریق Resolve یا نمونه‌سازی شود، دقیقاً تا پایان همان درخواست وب زنده خواهد ماند.
• آزادسازی خودکار (Automatic Disposal): فریم‌ورک ASP.NET Core در پایان چرخه عمر درخواست وب، به طور خودکار متد Dispose را روی سرویس‌های نمونه‌سازی شده فراخوانی می‌کند.

public class CustomMiddleware
{
    private readonly RequestDelegate _next;

    // سرویس‌های Singleton تنها می‌توانند سایر Singletonها یا Transientها را از طریق سازنده دریافت کنند.
    public CustomMiddleware(RequestDelegate next)
    {
        _next = next;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // نمونه‌سازی امن یک سرویس Scoped به ازای هر درخواست وب
        var dbContext = context.RequestServices.GetRequiredService<MyDbContext>();
        
        await _next(context);
    }
}

• پنهان‌سازی وابستگی‌ها (Hidden Dependencies): این الگو وابستگی‌های کلاس را از امضای سازنده (Constructor) حذف و آن‌ها را پنهان می‌کند. این امر فرآیند نوشتن آزمون‌های واحد (Unit Testing) را به شدت دشوار می‌سازد.
• ضد الگوی Service Locator: استفاده مکرر از این ساختار، کد را به سمت اتصال ناخواسته (Coupling) سوق داده و اصل وارونگی وابستگی (Dependency Inversion Principle) را نقض می‌کند.
• عدم ایمنی نخ‌ها (Thread Safety): شیء HttpContext به هیچ وجه Thread-safe نیست. استفاده از RequestServices درون کارهای موازی (مانند Task.WhenAll) که خارج از نخ اصلی درخواست اجرا می‌شوند، کانتینر را دچار فساد داده‌ای (Scope Corruption) می‌کند.

using Microsoft.AspNetCore.Http;
using Microsoft.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore.Diagnostics;
using Microsoft.Extensions.DependencyInjection;

public class AuditInterceptor : SaveChangesInterceptor
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public AuditInterceptor(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public override InterceptionResult<int> SavingChanges(
        DbContextEventData eventData, InterceptionResult<int> result)
    {
        UpdateAuditProperties(eventData.Context);
        return base.SavingChanges(eventData, result);
    }

    private void UpdateAuditProperties(DbContext? context)
    {
        if (context == null) return;

        var httpContext = _httpContextAccessor.HttpContext;
        if (httpContext == null) return; // مواقعی که درخواست وب وجود ندارد (مانند Migrationها یا Background Tasks)

        // نمونه‌سازی سرویس Scoped از دل کانتینر درخواست وب جاری
        var currentUserService = httpContext.RequestServices.GetRequiredService<ICurrentUserService>();
        var currentUserId = currentUserService.UserId;

        foreach (var entry in context.ChangeTracker.Entries<IAuditable>())
        {
            if (entry.State == EntityState.Added)
            {
                entry.Entity.CreatedBy = currentUserId;
            }
        }
    }
}

• نخ‌های پس‌زمینه و محتوای تهی (Null Contexts): اگر متد SaveChanges از طریق یک Background Worker، یک Job در Hangfire یا ابزار CLI مربوط به EF Migrations صدا زده شود، مقدار HttpContext تهی (null) خواهد بود و خطر خطای NullReferenceException وجود دارد.
• حلقه وابستگی متقابل (Stack Overflow Error): اگر سرویس ICurrentUserService خود برای یافتن اطلاعات کاربر نیاز به کوئری زدن روی همان DbContext داشته باشد، یک حلقه بی‌انتها شکل می‌گیرد:
• SaveChanges -> Interceptor -> RequestServices -> CurrentUserService -> DbContext Query -> SaveChanges
• این روند در نهایت منجر به کرش برنامه به دلیل خطای خطای سرریز پشته می‌شود.

// ❌ خطای منطقی در کدهای با معماری Pool
builder.Services.AddDbContextPool<MyDbContext>((sp, options) => {
    var interceptor = sp.GetRequiredService<AuditInterceptor>(); // سرویس در استارت‌آپ قفل می‌شود!
    options.AddInterceptors(interceptor);
});

public class AuditInterceptor : SaveChangesInterceptor
{
    private readonly ICurrentUserService _currentUserService;

    // تزریق کاملاً استاندارد و بدون نیاز به HttpContextAccessor
    public AuditInterceptor(ICurrentUserService currentUserService)
    {
        _currentUserService = currentUserService;
    }

    public override InterceptionResult<int> SavingChanges(
        DbContextEventData eventData, InterceptionResult<int> result)
    {
        // منطق حسابرسی با استفاده از _currentUserService
        return base.SavingChanges(eventData, result);
    }

}

public class ApplicationDbContext : DbContext
{
    private readonly IServiceProvider _serviceProvider;

    public ApplicationDbContext(
        DbContextOptions<ApplicationDbContext> options, 
        IServiceProvider serviceProvider) 
        : base(options)
    {
        _serviceProvider = serviceProvider;
    }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        // حل دینامیک اینترسپتور از Scope درخواست جاری در هر بار استفاده از پول
        var scopedInterceptor = _serviceProvider.GetRequiredService<AuditInterceptor>();
        optionsBuilder.AddInterceptors(scopedInterceptor);

        base.OnConfiguring(optionsBuilder);
    }

}

builder.Services.AddScoped<ICurrentUserService, CurrentUserService>();
builder.Services.AddScoped<AuditInterceptor>(); // ثبت به صورت Scoped

// ثبت به صورت Pool بدون دغدغه تداخل چرخه عمر سرویس‌ها
builder.Services.AddDbContextPool<ApplicationDbContext>(options =>
{
    options.UseSqlServer(builder.Configuration.GetConnectionString("DefaultConnection"));
});

• چرخه درخواست (Request Cycle): هسته EF Core یک نمونه از ApplicationDbContext را از Pool اجاره می‌کند.
• جابجایی محدوده (Scope Swap): فریم‌ورک EF Core به صورت داخلی زیرساخت‌های متصل به _serviceProvider کانتکست را با Scope درخواست HTTP جاری هماهنگ و به‌روزرسانی می‌کند.
• نمونه‌سازی دقیق (Resolution): متد OnConfiguring اجرا شده و دقیقاً نمونه AuditInterceptor مربوط به همان Request جاری را دریافت می‌کند. این رویکرد حتی در کارهای پس‌زمینه (Background Services) نیز در صورت ساخت دستی Scope به درستی کار خواهد کرد.