ASP.NET Core Web API中如何动态设置多请求模型的可选属性

可行性分析 #

完全可行，全局动作过滤器是这类场景的最优解之一。它能避免在每个Action中重复编写属性赋值逻辑，实现统一的请求模型属性注入，同时保持代码的整洁性和可维护性。

实现步骤 #

1. 定义标记接口 #

为需要注入的属性分别定义标记接口，让请求模型按需实现对应接口，替代反射提升性能和可读性：

public interface IHasUserId
{
    long UserId { get; set; }
}

public interface IHasChartId
{
    long ChartId { get; set; }
}

public interface IHasProvinceId
{
    long ProvinceId { get; set; }
}

示例：AcceptEvent 模型实现所有接口

public class AcceptEvent : IHasUserId, IHasChartId, IHasProvinceId
{
    public long UserId { get; set; }
    public long ChartId { get; set; }
    public long ProvinceId { get; set; }
    // 其他属性...
}

2. 实现全局动作过滤器 #

创建过滤器类，通过注入 IUserClaimsService 获取用户声明，然后为实现了标记接口的请求模型赋值：

public class InjectUserClaimsFilter : IActionFilter
{
    private readonly IUserClaimsService _userClaimsService;

    public InjectUserClaimsFilter(IUserClaimsService userClaimsService)
    {
        _userClaimsService = userClaimsService;
    }

    public void OnActionExecuting(ActionExecutingContext context)
    {
        // 定位请求模型（通常Action仅包含一个请求参数）
        var requestModel = context.ActionArguments.Values.FirstOrDefault(v => v != null);
        if (requestModel == null) return;

        // 按接口类型注入对应属性
        if (requestModel is IHasUserId hasUserIdModel)
        {
            hasUserIdModel.UserId = _userClaimsService.UserId;
        }

        if (requestModel is IHasChartId hasChartIdModel)
        {
            hasChartIdModel.ChartId = _userClaimsService.LoginChart;
        }

        if (requestModel is IHasProvinceId hasProvinceIdModel)
        {
            hasProvinceIdModel.ProvinceId = _userClaimsService.ProvinceId;
        }
    }

    public void OnActionExecuted(ActionExecutedContext context)
    {
        // 无需处理后置逻辑
    }
}

3. 注册过滤器 #

在 Program.cs 中注册过滤器为Scoped服务，并添加到全局过滤器集合：

// 注册过滤器
builder.Services.AddScoped<InjectUserClaimsFilter>();

// 配置Controllers并添加全局过滤器
builder.Services.AddControllers(options =>
{
    options.Filters.AddService<InjectUserClaimsFilter>();
});

性能注意事项 #

• 优先使用标记接口，避免反射：接口类型检查是CLR原生支持的操作，比反射遍历属性的性能高一个数量级，同时代码更易维护。
• 减少参数遍历开销：直接定位单个请求模型（而非遍历所有Action参数），避免无意义的循环。
• 复用Claims解析结果：你的 UserClaimsService 已经在请求初始化时完成Claims解析，过滤器中直接复用即可，不要重复解析HttpContext中的Claims。
• 空值与认证判断：在 UserClaimsService 中添加空值校验（如用 FirstOrDefault 替代 First），避免Claims缺失时抛出异常影响请求流程。

最佳实践 #

• 职责单一：过滤器仅负责属性注入，权限校验（如验证用户是否有权操作指定ChartId）应单独放在授权过滤器或Action逻辑中，避免逻辑耦合。
• 明确接口契约：新增请求模型时，仅为需要注入属性的模型实现对应接口，避免过度注入。
• 测试友好：依赖接口而非具体实现，单元测试时可轻松模拟 IUserClaimsService，无需依赖真实HttpContext。
• 异常防护：在 UserClaimsService 中处理Claims缺失的情况，比如给属性设置默认值或抛出特定业务异常，而非直接抛出 NullReferenceException。

内容的提问来源于stack exchange，提问作者Mehdi Raji