Как я могу получить больше контроля над моей маршрутизацией контроллера API в MVC Core?

Question

В старом Web API 2 мы использовали для настройки маршрутизации в WebApi.config так:

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

Так маршрут будет идти к контроллеру, указанный в первом сегменте URL, а затем к действию PreviewSomething или без действия по умолчанию, а затем имя метода, соответствующее HTTP-глаголу, или метод с атрибутом, соответствующим HTTP-глаголу запроса.

Сейчас в ASP.Net MVC Ядра, все, кажется, использует:

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); 
} 

Этот пример действительно сложным и абстрактным, чтобы быть полезным меня. Но предполагается поддерживать такие методы, как: MapGet и MapPost

ли атрибут маршрутизации более общепринятый способ в настоящее время? Это самый стандартный способ?

Answer 1

Да, общая рекомендация - использовать маршруты атрибутов для WebAPI. Однако вы можете полностью использовать маршруты стиля MVC, если это ваше предпочтение. Разница между этими двумя методами вы освещающих просто новый сокращенный синтаксис

При вводе

"{Controller=Foo}/..." 

Вы просто указать значение по умолчанию.

Новая система на самом деле намного более гибкая, чем WebAPI2, и вы можете построить намного более сложные схемы, если захотите. Если у вас нет веских причин, вы, вероятно, захотите пойти со встроенной поддержкой.

Последнее, а не итерация по списку маршрутов, таких как MVC и WebAPI, теперь имеет гораздо более эффективный алгоритм дерева структурированной маршрутизации, который делает маршрутизацию LOT дешевле, когда количество маршрутов велико (logN вместо N) , Вы заметите, что подпись UseMVC предоставляет построитель маршрутов, а не сборку маршрутов, в попытке абстрагировать фактический базовый механизм маршрутизации времени выполнения от времени настройки.

Вот несколько образцов передовой/пользовательской маршрутизации:

Using Action Constraints

Custom routing conventions

Custom routing sample

Последняя полная переделку того, как MVC работает Nancy стиль, бок о бок с существующая маршрутизация. Я бы не воспринял это как рекомендацию, а скорее способ показать гибкость системы и то, как далеко она может вас принять.

Nancy style routing inside MVC