ASP.NET MVC базовая маршрутизация без имени представления

Question

Это основной вопрос о механизмах маршрутизации. Из нового проекта MVC у меня есть это в HomeController:

public ActionResult MyPage()
{
  return View();
}

В папке Views \ Home у меня есть MyPage.aspx. Маршрутизация по-прежнему является значением по умолчанию {controller} / {action} / {id}. Когда я набираю http://localhost:1790/Home/MyPage,, это правильные маршруты к MyPage.aspx. Поскольку я ничего не сказал о том, какое представление следует визуализировать, как ASP.NET MVC узнает, как правильно перенаправить MyPage.aspx? Похоже, что имя ActionResult может также использоваться в качестве имени страницы View / aspx ... если только я не понимаю, как работает маршрутизация. Я вижу, как я попадаю в домашнюю папку, поскольку имя контроллера соответствует имени подпапки View. Но соответствует ли имя действия имени aspx?

Будет ли это работать, если страница была PHP?

Answer 1

ASP.NET MVC подписывается на так называемую парадигму «Соглашение о конфигурации», тогда как, если вы будете следовать их соглашениям, для вас произойдут основные вещи, такие как проблемы маршрутизации. Но они также позволяют вам настроить их при желании.

Answer 2

Как уже было сказано, ASP.NET MVC использует соглашение о конфигурации. Из вашей коробки структура папок выглядит примерно так (только показывает соответствующие части и делает это из памяти, так что ...)

Сайт Root

+ Controllers
    HomeController.cs
    AccountController.cs
+ Views
  + Home
      Index.aspx
  + Account
      Index.aspx
  + Shared

Обработчик маршрутизации по умолчанию выглядит примерно так:

  "{controller}/{action}/{id}"

Существуют значения по умолчанию для маршрута, но если у вас есть URL, который является / b / c, он будет искать действие a на контроллере aController и передает его в качестве параметра, если указанный метод на контроллере принимает параметры.

Несколько вещей об этом нужно уточнить. Снова, соглашение по конфигурации: 1) Все классы контроллеров должны заканчиваться контроллером, если вы используете движок по умолчанию. Таким образом, когда поступает запрос и анализируется значение {controller}, движок добавляет к нему контроллер, просматривает папку контроллера (и, следовательно, пространство имен) и находит класс. 2) По умолчанию - это можно изменить - все представления для контроллера должны находиться в папке Views / {controller} или в папке Views / Shared. 3) Публичные методы на контроллере по умолчанию являются действиями. Вы можете скрыть это с помощью атрибута, чтобы сделать метод недоступным для движка, но по умолчанию они общедоступны.

Таким образом, когда запрос поступает в маршрут, сравнивается со всеми известными маршрутами (global.asax), и первый маршрут, соответствующий запросу, принимается. Затем маршрут разбирается на составные части, чтобы определить контроллер, действие и параметры для действия.

Как только контроллер идентифицирован, механизм создает экземпляр этого контроллера и выполняет соответствующий метод (действие), если он найден.

Действие вернет ActionResult. View - это метод extensino, который на самом деле возвращает ViewResult (если я правильно помню). Представлением по умолчанию для действия является представление с тем же именем, что и у действия, находящегося в папке Views / {ControllerName}.

Маршрутизация - это зверь сам по себе, и я бы посоветовал почитать его, если вы собираетесь поиграть с ним. Минуты, чтобы понять, но жизнь, чтобы овладеть вещью Сорта.

Насколько я знаю, кстати, нет движка, который будет использовать страницу php как представление для действия контроллера.

Answer 3

Имя действия совпадает с именем представления / частичного имени.

Насколько мне известно, asp.net mvc не работает с php.

Answer 4

MVC неявно предполагает, что если вы возвращаете только View (), то вам нужен View («MyPage») (то есть имя действия). Нет смысла повторяться без необходимости.

Он не найдет файл PHP по умолчанию, но я уверен, что вы можете переопределить это поведение, если действительно захотите. Я не могу представить себе нормальный сценарий, когда вы будете смешивать PHP и ASP.NET MVC, но кто знает:)