MediatR在Blazor Server中的服务作用域管理实践

2025-05-20 08:11:40作者：宣聪麟

在Blazor Server应用中使用MediatR时，服务作用域管理是一个需要特别注意的技术点。本文将深入探讨这一问题的本质，分析现有解决方案的优缺点，并提出更优雅的实践方案。

问题背景

Blazor Server应用采用电路(Circuit)模型，每个用户连接会建立一个持久化的电路。在这个模型中，Scoped服务的生命周期与电路绑定，而非传统ASP.NET Core中的请求级别。这与MediatR通常的使用模式产生了根本性的冲突。

当我们在MediatR处理器(Handler)中注入Scoped服务时，这些服务实例会在整个电路生命周期内保持存活。这可能导致：

数据库上下文等资源长时间不释放
状态意外共享
并发问题
资源泄漏

传统解决方案分析

开发者通常采用以下两种方式解决这个问题：

1. 处理器内创建作用域

public class SomeHandler : IRequestHandler<SomeQuery>
{
    private readonly IServiceScopeFactory _scopeFactory;

    public SomeHandler(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    public async Task Handle(SomeQuery request, CancellationToken ct)
    {
        using var scope = _scopeFactory.CreateScope();
        var service = scope.ServiceProvider.GetRequiredService<ISomeService>();
        // 使用服务...
    }
}

优点：

明确控制服务生命周期
每个请求获得全新服务实例

缺点：

代码重复
手动解析服务不够优雅
容易忘记创建作用域

2. 管道行为(Pipeline Behavior)

public class ScopedBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
    private readonly IServiceScopeFactory _scopeFactory;

    public ScopedBehavior(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    public async Task<TResponse> Handle(TRequest request, CancellationToken ct, RequestHandlerDelegate<TResponse> next)
    {
        using var scope = _scopeFactory.CreateScope();
        // 如何将作用域传递给处理器?
        return await next();
    }
}

优点：

集中管理作用域
减少重复代码

缺点：

难以将作用域传递给处理器
通知处理器(Notification Handler)难以共享同一作用域

进阶解决方案

自定义作用域标记属性

我们可以设计一个自定义属性来标记需要从请求作用域解析的服务：

[AttributeUsage(AttributeTargets.Parameter)]
public class FromRequestScopeAttribute : Attribute { }

public class SomeHandler : IRequestHandler<SomeQuery>
{
    private readonly ISomeService _service;

    public SomeHandler([FromRequestScope] ISomeService service)
    {
        _service = service;
    }
    // ...
}

实现方案

自定义服务提供者工厂：

public class RequestScopedServiceProvider : IServiceProvider
{
    private readonly IServiceProvider _circuitProvider;
    private readonly IServiceScope _requestScope;

    public RequestScopedServiceProvider(IServiceProvider circuitProvider)
    {
        _circuitProvider = circuitProvider;
        _requestScope = circuitProvider.CreateScope();
    }

    public object GetService(Type serviceType)
    {
        // 优先从请求作用域解析
        return _requestScope.ServiceProvider.GetService(serviceType) 
            ?? _circuitProvider.GetService(serviceType);
    }

    public void Dispose() => _requestScope.Dispose();
}

集成到MediatR管道：

public class ScopedBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
    private readonly IServiceScopeFactory _scopeFactory;

    public ScopedBehavior(IServiceScopeFactory scopeFactory)
    {
        _scopeFactory = scopeFactory;
    }

    public async Task<TResponse> Handle(TRequest request, CancellationToken ct, RequestHandlerDelegate<TResponse> next)
    {
        using var scope = _scopeFactory.CreateScope();
        var requestServices = new RequestScopedServiceProvider(scope.ServiceProvider);
        
        // 将requestServices传递给处理器...
        return await next();
    }
}

通知处理器的特殊考虑

通知处理器(Notification Handler)需要特别注意，因为它们可能由请求处理器触发，但运行在不同的上下文中。为确保一致性：

在发布通知时传递当前作用域
使用自定义的发布策略确保通知处理器使用正确的作用域

public class ScopedPublisher : INotificationPublisher
{
    public async Task Publish(IEnumerable<NotificationHandlerExecutor> handlers, INotification notification, CancellationToken ct)
    {
        // 从当前上下文获取作用域
        var scope = GetCurrentScope();
        
        foreach (var handler in handlers)
        {
            using var handlerScope = scope.CreateScope();
            var handlerInstance = handlerScope.ServiceProvider.GetService(handler.HandlerType);
            await handler.HandlerCallback(handlerInstance, notification, ct);
        }
    }
}