如何在C#中为ActionFilter引入新版本逻辑（兼容旧代码）

我正在修改现有C#应用的安全处理逻辑，最终要替换成一个和当前完全不同的新User对象，但必须以不破坏旧代码的方式引入这个新模型，在完成全量迁移前需要同时支持两种安全校验逻辑。

当前代码逻辑 #

用户登录时，从数据库加载包含权限列表的用户Profile，通过继承自ActionFilterAttribute并实现IAuthorizationFilter的SecuredEndpoint特性，在OnActionExecuting方法中校验权限。示例代码如下：

接口示例 #

[Route("me/permissions")]
[HttpGet]
[SecuredEndpoint(WidgetAppPermissions.General)]
public string DoSomethingAmazing(GetAmazingDataRequest request)
{
    try
    {               
        var x = someAmazingObject.DoSomething();
        return JsonConvert.SerializeObject(x);
    }
    catch (Exception ex)
    {
        return ex.Message.ToString();
    }
}

请求类示例 #

public class GetAmazingDataRequest : Request
{
   
}

权限校验特性示例 #

public sealed class SecuredEndpointAttribute : ActionFilterAttribute, IAuthorizationFilter
{
    private readonly WidgetAppPermissions[] functions;

    public SecuredEndpointAttribute(params WidgetAppPermissions[] functions)
    {
        this.functions = functions;
    }

    public override void OnActionExecuting(ActionExecutingContext context)
    {
        // 在此方法中调用GetUserProfile从数据库加载含权限的用户Profile
        var user = userRepo.GetUserProfile(context.HttpContext.User);
    }
}

尝试的方案 #

我在Request基类中添加了securityVersionBeta属性，然后在OnActionExecuting方法里根据这个属性的值来判断执行新的还是旧的校验逻辑：

修改后的请求基类与子类 #

public class Request
{
   public virtual bool securityVersionBeta {get; set;} = false; 
}

public class GetAmazingDataRequest : Request
{
   public virtual bool securityVersionBeta {get; set;} = true;
}

修改后的权限校验逻辑 #

public override void OnActionExecuting(ActionExecutingContext context)
{
    if (((GetAmazingDataRequest )context.ActionArguments["Request"]).securityVersionBeta)
    {
        newProfileLogic(context);
    } else
    {
        Originalcode(context);
    }
}

我的疑问 #

这个方案有没有明显的缺陷？有没有其他可以逐步迁移代码的方案？求相关优化建议。

解答 #

现有方案的缺陷

• 强类型转换风险：context.ActionArguments["Request"]的类型不一定是GetAmazingDataRequest，如果其他请求类参数名不是"Request"、或者未正确继承基类，会直接抛出类型转换异常导致接口崩溃。
• 侵入性过高：需要修改所有请求类（包括基类）添加开关属性，迁移完成后还要清理这些冗余代码，额外增加维护成本。
• 逻辑耦合严重：权限校验逻辑和请求类的属性绑定，违反单一职责原则，后续扩展新安全版本会更复杂。
• 控制灵活性差：只能通过请求类硬编码属性控制版本，无法通过配置、请求头等方式动态切换，不利于灰度发布或临时回滚。

替代方案与优化建议

方案1：基于特性标记的版本切换

给需要使用新安全逻辑的接口单独添加标记特性，在SecuredEndpoint中检测该特性来选择校验逻辑：

// 新增标记特性
[AttributeUsage(AttributeTargets.Method)]
public class UseNewSecurityAttribute : Attribute { }

// 修改接口，添加标记
[Route("me/permissions")]
[HttpGet]
[SecuredEndpoint(WidgetAppPermissions.General)]
[UseNewSecurity] // 标记使用新逻辑
public string DoSomethingAmazing(GetAmazingDataRequest request)
{
    // ... 原有逻辑
}

// 修改SecuredEndpoint的校验逻辑
public override void OnActionExecuting(ActionExecutingContext context)
{
    var useNewSecurity = context.ActionDescriptor.EndpointMetadata.Any(m => m is UseNewSecurityAttribute);
    if (useNewSecurity)
    {
        newProfileLogic(context);
    }
    else
    {
        Originalcode(context);
    }
}

优点：对现有请求类无侵入，开关控制灵活，迁移完成后直接删除标记特性即可。

方案2：基于请求头的动态切换

通过自定义请求头（比如X-Security-Version）指定安全版本，无需修改业务代码即可动态切换：

public override void OnActionExecuting(ActionExecutingContext context)
{
    if (context.HttpContext.Request.Headers.TryGetValue("X-Security-Version", out var version) 
        && version.Equals("beta", StringComparison.OrdinalIgnoreCase))
    {
        newProfileLogic(context);
    }
    else
    {
        Originalcode(context);
    }
}

优点：完全无侵入，支持灰度发布、A/B测试，临时回滚只需调整客户端请求头，适合需要灵活控制的场景。

方案3：拆分权限校验特性

直接创建新的权限校验特性SecuredEndpointV2，让需要迁移的接口直接替换原有特性：

public sealed class SecuredEndpointV2Attribute : ActionFilterAttribute, IAuthorizationFilter
{
    private readonly WidgetAppPermissions[] functions;

    public SecuredEndpointV2Attribute(params WidgetAppPermissions[] functions)
    {
        this.functions = functions;
    }

    public override void OnActionExecuting(ActionExecutingContext context)
    {
        newProfileLogic(context);
    }
}

// 迁移后的接口
[Route("me/permissions")]
[HttpGet]
[SecuredEndpointV2(WidgetAppPermissions.General)]
public string DoSomethingAmazing(GetAmazingDataRequest request)
{
    // ... 原有逻辑
}

优点：新旧逻辑完全解耦，迁移过程清晰，后续直接删除旧特性及相关代码即可。

方案4：依赖注入+策略模式

定义权限校验策略接口，分别实现新旧两种策略，根据配置或请求信息动态选择：

// 定义策略接口
public interface IPermissionValidationStrategy
{
    void Validate(ActionExecutingContext context, WidgetAppPermissions[] functions);
}

// 旧策略实现
public class LegacyPermissionStrategy : IPermissionValidationStrategy
{
    private readonly IUserRepo _userRepo;
    public LegacyPermissionStrategy(IUserRepo userRepo) => _userRepo = userRepo;

    public void Validate(ActionExecutingContext context, WidgetAppPermissions[] functions)
    {
        // 原有校验逻辑
        var user = _userRepo.GetUserProfile(context.HttpContext.User);
    }
}

// 新策略实现
public class NewPermissionStrategy : IPermissionValidationStrategy
{
    private readonly INewUserRepo _newUserRepo;
    public NewPermissionStrategy(INewUserRepo newUserRepo) => _newUserRepo = newUserRepo;

    public void Validate(ActionExecutingContext context, WidgetAppPermissions[] functions)
    {
        // 新校验逻辑
        var newUser = _newUserRepo.GetNewUser(context.HttpContext.User);
    }
}

// 修改SecuredEndpoint
public sealed class SecuredEndpointAttribute : ActionFilterAttribute, IAuthorizationFilter
{
    private readonly WidgetAppPermissions[] functions;

    public SecuredEndpointAttribute(params WidgetAppPermissions[] functions)
    {
        this.functions = functions;
    }

    public override void OnActionExecuting(ActionExecutingContext context)
    {
        var serviceProvider = context.HttpContext.RequestServices;
        // 这里可结合特性标记/请求头选择策略
        var useNew = context.ActionDescriptor.EndpointMetadata.Any(m => m is UseNewSecurityAttribute);
        var strategy = useNew 
            ? serviceProvider.GetRequiredService<NewPermissionStrategy>() 
            : serviceProvider.GetRequiredService<LegacyPermissionStrategy>();
        
        strategy.Validate(context, functions);
    }
}

优点：符合开闭原则，扩展性强，后续新增安全版本只需添加新策略实现，无需修改原有逻辑，适合长期维护的大型应用。

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