如何实现MVC中Action与ID同级的路由？是否属不良设计？

一、完全可行，且是合理的路由设计需求 #

你想要的这种URL结构（/F/ActionName 对应Action，/F/ID 对应ID处理）完全符合MVC路由的匹配逻辑，只要合理设置路由的优先级就能实现，而且能直接解决你之前手动逐个加Action路由导致的混乱问题。

二、具体实现步骤 #

MVC的路由是从上到下匹配的，所以我们要先配置「匹配明确Action」的路由，再配置「兜底处理ID」的路由，避免ID被误匹配成Action。

1. 基础实现：手动指定Action列表 #

在你的RouteConfig.cs里，按顺序添加以下路由：

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    // 第一步：匹配F控制器下的明确Action
    routes.MapRoute(
        name: "F_Action_Routes",
        url: "F/{action}",
        defaults: new { controller = "F" },
        // 这里列出所有F控制器下的合法Action名称，用|分隔
        constraints: new { action = "GetMyData|UpdateInfo|DeleteItem" }
    );

    // 第二步：兜底匹配ID，当上面的路由不命中时生效
    routes.MapRoute(
        name: "F_ID_Route",
        url: "F/{id}",
        // 指定处理ID的Action，比如在F控制器里写一个HandleID方法
        defaults: new { controller = "F", action = "HandleID" }
    );

    // 保持默认路由在最后
    routes.MapRoute(
        name: "Default",
        url: "{controller}/{action}/{id}",
        defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
    );
}

然后在FController中添加对应的处理方法：

public class FController : Controller
{
    // 处理明确的Action请求
    public ActionResult GetMyData()
    {
        // 你的业务逻辑
        return View();
    }

    // 处理ID请求
    public ActionResult HandleID(string id)
    {
        // 用id做业务处理，比如查询对应资源
        return View();
    }
}

这样一来：

• 当请求http://www.something.com/F/GetMyData时，会匹配第一个路由，调用GetMyData Action；
• 当请求http://www.something.com/F/dfeTD53F且这个字符串不在Action列表里时，会匹配第二个路由，把dfeTD53F作为id参数传给HandleID Action。

2. 进阶优化：自动匹配控制器中的Action #

如果F控制器的Action很多，手动维护constraints里的列表太麻烦，可以自定义一个路由约束，自动检查F控制器中是否存在对应的Action方法：

public class ActionExistsConstraint : IRouteConstraint
{
    private readonly Type _controllerType;

    public ActionExistsConstraint(Type controllerType)
    {
        _controllerType = controllerType;
    }

    public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection)
    {
        if (values.TryGetValue(parameterName, out var actionValue) && actionValue is string actionName)
        {
            // 检查控制器中是否存在该名称的公共非静态方法（即合法Action）
            return _controllerType.GetMethods().Any(m => 
                m.Name.Equals(actionName, StringComparison.OrdinalIgnoreCase) && 
                m.IsPublic && !m.IsStatic);
        }
        return false;
    }
}

然后修改路由配置，用这个自定义约束替代手动的Action列表：

routes.MapRoute(
    name: "F_Action_Routes",
    url: "F/{action}",
    defaults: new { controller = "F" },
    constraints: new { action = new ActionExistsConstraint(typeof(FController)) }
);

这样就不用手动维护Action列表了，路由会自动识别F控制器里的所有合法Action，更灵活省心。

三、这种设计是不是不良应用设计？ #

答案是不一定，关键看你的业务场景和处理细节：

优点： #

• URL更简洁友好，符合RESTful风格的资源定位思路；
• 解决了你之前手动配置大量Action路由的混乱问题，路由配置更集中清晰；
• 区分了「操作（Action）」和「资源（ID）」的层级，逻辑更直观。

需要注意的潜在问题： #

• 命名冲突：如果ID的格式和Action名称有重叠（比如某个ID刚好是某个Action的名字），会导致路由匹配错误。解决办法是给ID设置格式约束（比如用正则限制ID必须包含大写字母和数字，像你例子里的dfeTD53F），或者给Action设置明确的命名规则（比如全小写、带前缀等），避免和ID格式重叠；
• 路由优先级：一定要把Action路由放在ID路由前面，否则所有请求都会先匹配ID路由，导致Action无法被正确调用。

只要处理好这些细节，这种设计不仅不是不良设计，反而能让你的路由结构更清晰，用户体验更好。

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