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

Question

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

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

Есть ли новые ожидания относительно того, какие типы представлений содержатся в этих каталогах?Например, должна ли страница по умолчанию для каждого каталога быть 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:

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

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

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