如何在 MVC Core 中更好地控制我的 API 控制器路由？答案

【问题标题】：How can I gain more control over my API controller routing in MVC Core?如何在 MVC Core 中更好地控制我的 API 控制器路由？
【发布时间】：2017-02-07 21:11:17
【问题描述】：

在旧的 Web API 2 中，我们曾经像这样在 WebApi.config 中设置路由：

Map(routes, "MyNamedRoute", "{controller}/custom/preview",
            new {action = "PreviewSomthing"});

因此，路由将转到 URL 的第一段中命名的控制器，然后转到 PreviewSomething 操作，或者没有默认操作，然后是与 HTTP 动词匹配的方法名称或具有与 HTTP 动词匹配的属性的方法请求。

现在在 ASP.Net MVC Core 中，似乎每个人都在使用：

app.UseMvc(routes =>
        {
            routes.MapRoute(
               name: "default",
               template: "{controller=Home}/{action=Index}/{id?}");
        });

用于纯 MVC 类型路由与 Web API 控制器的属性路由混合。

现在这是否被认为是最佳做法？我更喜欢实际定义我的路线的更多控制。看起来他们会更容易测试。除非某处仍有路由集合对象，否则我们仍然可以访问测试路由。

在这篇文章中： https://docs.microsoft.com/en-us/aspnet/core/fundamentals/routing 有一节叫做：“使用路由中间件”。

你需要：

services.AddRouting()

在startup.cs的配置中

这是他们给出的例子：

public void Configure(IApplicationBuilder app, ILoggerFactory loggerFactory)
{
    var trackPackageRouteHandler = new RouteHandler(context =>
    {
        var routeValues = context.GetRouteData().Values;
        return context.Response.WriteAsync(
            $"Hello! Route values: {string.Join(", ", routeValues)}");
    });

    var routeBuilder = new RouteBuilder(app, trackPackageRouteHandler);

    routeBuilder.MapRoute(
        "Track Package Route",
        "package/{operation:regex(^track|create|detonate$)}/{id:int}");

    routeBuilder.MapGet("hello/{name}", context =>
    {
        var name = context.GetRouteValue("name");
        // This is the route handler when HTTP GET "hello/<anything>"  matches
        // To match HTTP GET "hello/<anything>/<anything>,
        // use routeBuilder.MapGet("hello/{*name}"
        return context.Response.WriteAsync($"Hi, {name}!");
    });

    var routes = routeBuilder.Build();
    app.UseRouter(routes);
}

这个例子真的很复杂和抽象，对我有用。但它应该支持以下方法：地图获取和地图邮政

现在属性路由是更被接受的方式吗？这是最标准的方式吗？

【问题讨论】：

标签： asp.net-web-api asp.net-core-mvc asp.net-core-routing

【解决方案1】：

是的，一般建议是为 WebAPI 使用属性路由。但是，如果这是您的偏好，您可以完全使用 MVC 风格的路线。您强调的两种技术之间的区别只是一种新的速记语法

当你输入时

"{Controller=Foo}/..."

您只需指定默认值。

新系统实际上比 WebAPI2 灵活得多，如果您愿意，您可以构建更复杂的方案。如果您没有充分的理由，您可能希望使用内置支持。

最后不是像 MVC 和 WebAPI 那样迭代路由列表，现在有一种更有效的树形结构路由算法，当路由数量很大时（logN 而不是 N），这使得路由更便宜。您会注意到 UseMVC 的签名公开了一个路由构建器而不是一个路由集合，以便从配置时抽象出实际的底层运行时路由机制。

以下是一些高级/自定义路由示例：

Using Action Constraints

Custom routing conventions

Custom routing sample

最后一个完整的重做 MVC 如何工作 Nancy 风格，与现有路由并排。我不会将此作为建议，而是更多地展示系统的灵活性以及它可以带您走多远的方式。

Nancy style routing inside MVC

【讨论】：