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

Именование каталогов представления и именование файлов важны, потому что платформа 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. Я показываю эту технику в это сообщение в блоге, но имена типов другие, поскольку она была написана для более ранней версии фреймворка. Однако основная идея осталась прежней.

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

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

• / orders / (т.е. индекс)
• / orders / show / 123
• / orders / edit / 123
• / orders / update / 123
• / orders / new
• / orders / create
• / заказы / уничтожить / 123

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

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