如何重构MVC登录场景中依赖控制器变量的switch分支语句

最优重构方案：上下文绑定 + 策略模式实现 #

核心逻辑：你不需要把控制器的变量逐个拆分传递，直接将LoginController本身作为登录上下文对象注入到各登录策略的实现类中，所有登录逻辑直接操作上下文的公共属性/方法即可，既避免了大量参数传递，又能完整复用控制器现有逻辑。

步骤1：定义登录策略接口 #

首先统一所有登录方式的执行流程契约，和你现有Login方法的三个检查步骤对齐：

public interface ILoginHandler
{
    void CheckX(LoginController context);
    void CheckY(LoginController context);
    void CheckZ(LoginController context);
}

步骤2：为每种登录类型实现独立的策略类 #

每个类型的逻辑单独封装，不需要重复写switch：

// 用户名密码登录实现
public class DefaultLoginHandler : ILoginHandler
{
    public void CheckX(LoginController context)
    {
        context.username = Console.ReadLine();
    }

    public void CheckY(LoginController context)
    {
        // 原有DEFAULT类型的CheckY逻辑
    }

    public void CheckZ(LoginController context)
    {
        // 原有DEFAULT类型的CheckZ逻辑
    }
}

// 刷卡登录实现
public class CardLoginHandler : ILoginHandler
{
    public void CheckX(LoginController context)
    {
        context.username = context.readFromCard();
        context.serverCertificate = context.checkDeviceCertificate();
    }

    public void CheckY(LoginController context)
    {
        context.serverCertValid = context.checkIfValidate(context.serverCertificate);
    }

    public void CheckZ(LoginController context)
    {
        // 原有CARD类型的CheckZ逻辑
    }
}

// API登录实现
public class ApiLoginHandler : ILoginHandler
{
    public void CheckX(LoginController context)
    {
        context.username = context.getUsernameRequest();
        context.serverVersion = context.readServerVersionFromX();
    }

    public void CheckY(LoginController context)
    {
        // 原有API类型的CheckY逻辑
    }

    public void CheckZ(LoginController context)
    {
        // 原有API类型的CheckZ逻辑
    }
}

步骤3：实现简单工厂来生成对应登录策略 #

把登录类型和策略类的映射关系单独维护：

public static class LoginHandlerFactory
{
    public static ILoginHandler GetHandler(LoginTypes loginType)
    {
        return loginType switch
        {
            LoginTypes.DEFAULT => new DefaultLoginHandler(),
            LoginTypes.CARD => new CardLoginHandler(),
            LoginTypes.API => new ApiLoginHandler(),
            _ => throw new NotSupportedException("不支持的登录类型")
        };
    }
}

步骤4：改造LoginController，删除所有冗余switch #

public class LoginController
{
    public string username { get; set; }
    public Certificate serverCertificate { get; set; }
    public Version serverVersion { get; set; }
    public bool serverCertValid { get; set; }

    public LoginTypes loginType;
    // 持有当前登录策略实例
    private ILoginHandler _loginHandler;

    public LoginController()
    {
        // 初始化时根据登录类型获取对应策略
        _loginHandler = LoginHandlerFactory.GetHandler(loginType);
    }

    void Login()
    {
        // 直接调用策略的对应方法，把自身作为上下文传入
        _loginHandler.CheckX(this);
        _loginHandler.CheckY(this);
        _loginHandler.CheckZ(this);
    }

    // 原有控制器的公共方法保留，供策略类调用
    public string readFromCard() => /*原有实现*/;
    public Certificate checkDeviceCertificate() => /*原有实现*/;
    public string getUsernameRequest() => /*原有实现*/;
    public Version readServerVersionFromX() => /*原有实现*/;
    public bool checkIfValidate(Certificate cert) => /*原有实现*/;
}

重构收益 #

• 完全消除重复的switch分支，后续新增登录类型只需要新增ILoginHandler的实现类，在工厂中加一行映射即可，符合开闭原则
• 每种登录方式的逻辑独立维护，不会互相影响，排查问题更高效
• 不需要拆分传递控制器的变量，所有原有逻辑都可以最小改动复用，避免重构引入bug
• LoginController只负责流程编排，不再耦合具体登录逻辑，职责更清晰

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