Как отмечают другие в комментариях, эти маршруты определенно жестко запрограммированы, но это может не представлять реальной проблемы. Было бы полезно лучше понять, какие требования являются причиной этой проблемы, поскольку решение в конечном итоге будет зависеть от этого. В то же время я могу предоставить некоторые рекомендации на высоком уровне, основанные на распространенном сценарии ios.
Одноуровневое веб-приложение
Если ваши контроллеры распространяются как часть вашего веб-приложения, и ваши маршруты всегда определены во время разработки (т. е. как часть вашего процесса разработки), тогда это просто предпочтение стилиста c относительно того, являются ли пути маршрутов жестко закодированными как часть ваших контроллеров или жесткими кодируется как часть вашего Startup класса. Это типичный сценарий для большинства веб-приложений .
Распространяемая библиотека классов
Если вы распространяете ваши контроллеры как часть библиотеки классов (или Razor Class Library), которая предназначена для использования в нескольких веб-приложениях, тогда это более важный вопрос. В этом сценарии жесткое кодирование маршрутов как части вашего контроллера не позволяет потребителям вашей библиотеки классов изменять пути.
Этот может быть полезным, если вы хотите, чтобы всегда использовались одни и те же маршруты, одновременно устраняя необходимость их настройки для каждого приложения. Но может быть вместо имеет смысл разрешить каждому приложению настраивать эти маршруты в своем классе Startup, что дает пользователям гибкость в настройке места расположения конечных точек вашей библиотеки. Если это так, то жесткое кодирование этих значений в контроллерах библиотеки классов нежелательно.
Методы расширения
Если последнее является требованием, обычно включают метод расширения для IRouteBuilder и / или IEndpointRouteBuilder, чтобы потребители могли легко настраивать маршруты для вашей библиотеки, принимая параметры для любых переменных, которые, как вы ожидаете, они будут переопределять, таких как префикс пути. Это обеспечивает баланс между гибкостью и простотой настройки. Например, это может выглядеть примерно так:
public static ControllerActionEndpointConventionBuilder MapEmployeeRoute(
this IEndpointRouteBuilder routes,
string pathPrefix = "Employee",
string controller = "Employee",
string action = "Index"
) =>
routes.MapControllerRoute(
name: "Employee-" + pathPrefix?.Replace("/", "", System.StringComparison.OrdinalIgnoreCase),
pattern: pathPrefix?.Trim('/') + "/{action}",
defaults: new { controller, action, pathPrefix }
);
, который можно использовать с любым из следующих вызовов:
public static void Configure(IApplicationBuilder app, IWebHostEnvironment env) {
…
app.UseRouting();
app.UseEndpoints(endpoints => {
endpoints.MapEmployeeRoute(); //Maps /Employee
endpoints.MapEmployeeRoute("Administration/Staff"); //Maps /Administration/Staff/
endpoints.MapEmployeeRoute("/Administration/Staff/"); //Tolerate variations
endpoints.MapEmployeeRoute("Staff", "MyEmployee"); //Reference derived controller
endpoints.MapEmployeeRoute("Staff", "Employee", "Add"); //Default to the Add() action
});
}
Dynami c Конфигурация маршрута
Примечание: Это довольно необычный сценарий, и поэтому я не решаюсь даже упомянуть его. Тем не менее, я включил его для полноты в случае, если это относится к вашим требованиям.
Еще один сценарий, когда жесткое кодирование маршрутов может быть проблемой, если по какой-то причине они вам нужны динамически настраиваться во время выполнения и / или использовать значения конфигурации из внешнего источника данных.
Например, если вы строите платформу как службу (PAAS), иногда желательно предоставить веб-интерфейс, где пользователи могут настраивать маршруты, связанные с конкретными службами, а затем динамически регистрировать их вместо жестко закодировать их в самой платформе. Это гораздо более сложный подход.