Какой должна быть структура файла / каталога вида в ASP.NET MVC?

Question

Я запутался в том, как организованы представления, и это важно понимать, поскольку ASP.NET MVC использует соглашения, чтобы все работало правильно.

В каталоге views находятся подкаталоги. Внутри этих подкаталогов находятся представления. Я предполагаю, что подкаталоги отображаются на контроллеры, а контроллеры действуют на представления, содержащиеся в их подкаталогах.

Есть ли ожидание того, какие типы представлений содержатся в этих каталогах? Например, должна ли страница по умолчанию для каждого каталога быть index.aspx? Должны ли страницы соответствовать соглашениям об именах, таким как Create [controller] .aspx, List [controller] .aspx и т. Д.? Или это не имеет значения?

Answer 1

Просмотр имен каталогов и имен файлов важен, потому что структура ASP.NET MVC делает определенные предположения о них. Если вы не соответствуете этим предположениям, то вы должны написать код, чтобы платформа знала, что вы делаете. Вообще говоря, вы должны соответствовать этим предположениям, если у вас нет веских причин не делать этого.

Давайте рассмотрим простейшее из возможных действий контроллера:

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

Поскольку в вызове View () имя представления не было указано, платформа будет предполагать, что имя файла представления будет таким же, как имя действия. Фреймворк имеет тип ViewEngine, который будет предоставлять расширение. По умолчанию ViewEngine - это WebFormViewEngine, который примет это имя и добавит к нему .aspx. Таким образом, полное имя файла в этом случае будет NotAuthorized.aspx.

Но в какой папке будет найден файл? Опять же, ViewEngine предоставляет эту информацию. С WebFormViewEngine он будет выглядеть в двух папках: ~ / Views / Shared и ~ / Views / {controller}

Так что если ваш контроллер называется AccountController, он будет выглядеть в ~ / Views / Account

Но могут быть случаи, когда вы не хотите следовать этим правилам. Например, два разных действия могут возвращать одно и то же представление (с другой моделью или чем-то еще). В этом случае, если вы явно указываете имя представления в своем действии:

    public ActionResult NotAuthorized()
    {
        return View("Foo");
    }

Обратите внимание, что в WebFormViewEngine «имя представления», как правило, совпадает с именем файла, за исключением расширения, но для каркаса это не требуется для других механизмов представления.

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

Answer 2

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

Как вы намекали в своем вопросе, возможно, что некоторые из этих представлений (или, точнее, действий, которые их отображают) станут популярными по всем направлениям, как, например, приведенные ниже, которые распространены в приложениях RoR, которые принимают REST-парадигма:

• / заказы / (то есть индекс)
• / заказы / шоу / 123
• / заказы / редактировать / 123
• / заказы / обновление / 123
• / заказы / новый
• / заказы / создать
• / заказы / уничтожить / 123

Выбор / стандартизация представлений в значительной степени зависит от того, как вы моделируете свое приложение (чтобы сказать очевидное) и от того, насколько детализированными вы хотите стать. Чем ближе вы сопоставляете свои контроллеры с отдельными классами моделей (кашель ... ресурсы ... кашель), тем короче будут ваши действия, и тем легче вы сможете выполнять стандартный набор действий (как в приведенном выше примере). ).

Я также считаю, что более короткие действия помогают внедрять все больше и больше бизнес-логики модели в сами модели, где она и принадлежит.