Помощь с маршрутами MVC 3 - PullRequest
       61

Помощь с маршрутами MVC 3

2 голосов
/ 12 августа 2011

В моем приложении MVC 3 есть простая структура маршрутов, которая неожиданно ломается.

Моя структура URL довольно проста, но содержит несколько переменных.

http://site.com/{location}/{stage}/{controller}/{action}/{id}

примеры:

Я создал следующий маршрут в моем файле Global.asax.

routes.MapRoute("Default", "{location}/{stage}/{controller}/{action}/{id}", new {controller="server", action="list", id = UrlParameter.Optional});

Это прекрасно работает для отображения списка серверов и сведений о сервере по адресу / server / details / id, но когда я пытаюсь выполнить перезагрузку, я получаю ошибку.

URL: http://site.com/ny/prod/server/reboot/565656

Представление 'ny' или его мастер не найдены, или никакой движок представления не поддерживает найденные местоположения.Были найдены следующие местоположения: ...

Почему он пытается найти имя представления ny.cshtml?

1 Ответ

0 голосов
/ 18 августа 2011

я думаю, что ваша проблема в том, что вы либо не используете ограничение для определения того, как должно выглядеть местоположение и этап, и оно дает вам ложные срабатывания и читает вещи там, где они не должны, или у вас есть определения вашего маршрута в неправильный заказ

убедитесь, что у вас задан mvc по умолчанию, заданный последним, и если у вас есть несколько пользовательских маршрутов, ограничьте использование регулярного выражения или пользовательского класса ограничений, чтобы определить, какие расположения допустимы, и они должны выглядеть как

например http://site.com/ny/test/server/123456

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

  • - это тест на допустимую стадию - регулярных выражений может быть достаточно, но я всегда стараюсь избегать регулярных выражений, когда это возможно, поскольку это зло и его трудно поддерживать. Опять же, я бы написал собственное ограничение, чтобы определить, какие этапы действительны. Вероятно, проверка по списку достаточна, так как у вас не должно быть очень много этапов. Также следует отметить, что при использовании этапов в том виде, в котором вы находитесь в своем URL, вы также можете добавить правила проверки подлинности в ограничение, чтобы, например, исключать только тех людей, которые ... скажем .. роли администратора или заинтересованных сторон сопоставляются с маршрутом и регулярно или не проходят проверку подлинности пользователи могут просто перейти к следующему маршруту или могут просто дать 404

Написание маршрутов может быть сложным, поэтому рекомендуется максимально ограничить ваши входные данные, особенно если вы принимаете строковые данные

Стивен Уолтер имеет хороший пост по написанию ограничения маршрута в своем блоге

...