Структура представления ASP.Net MVC

Я только что закончил учебник Scott Gu Nerd Diner. Я нашел это очень полезным, потому что он не только преподавал основы ASP.Net MVC, но и как использовать с репозиториями, валидацией, модульным тестированием, Ajax и т.д. Очень важно, но все же управляем.

Однако мне интересно узнать о его структуре сайта:

В частности, он использовал это представление для каждого объекта:
/ModelObject/Edit/
/ModelObject/ Создать/

Затем извлекли общие элементы между двумя представлениями и поместили их в частичный.

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

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

Спасибо!

[Изменить для пояснений]

Я понимаю, что много раз необходимо, чтобы было несколько действий (и представлений) для обработки различий в создании и редактировании. Это относится к очень простому редактированию и созданию, где единственное различие между двумя действиями заключается в одном случае, когда модель имеет идентификатор и нуждается в обновлении, а в другом случае модель отсутствует, поэтому она должна быть вставлены.

В этом случае это нарушение правила "Тупой взгляд", используя тот же вид, чтобы обрабатывать оба случая, чтобы вызвать серьезные проблемы?

Ответ 1

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

Стандартно иметь действия типа CRUD на контроллере, когда они применимы:

Индекс: список элементов
Подробности: просмотр определенного элемента
Изменить: отредактировать элемент
Создать: новый элемент
Удалить: удалить элемент

Для каждого из этих действий потребуется представление (а иногда и несколько).

Итак, да, вы можете собирать большое количество просмотров, если это большое приложение. Способ минимизации кода:

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

Важно отметить, что любое большое приложение будет иметь множество форм. Будь то Mvc или Web Forms, если есть много данных для работы, там будет много форм, необходимых для этого.

Ответ 2

Это правда, что это действительно может поддаваться многим взглядам. Тем не менее, я обнаружил, что в реальных приложениях для жизни у меня будет несколько таблиц, в которых у меня нет корреляции 1:1 с операциями CRUD. Хотя у меня есть данные, которые входят в эти таблицы, я обнаружил, что в большинстве случаев представление представляет данные из по меньшей мере двух, если не трех или более таблиц. Как и все другие приложения, вы должны знать, что вам нужно, чтобы вы могли планировать все. Для любого приложения большого размера потребуется довольно много планирования спереди (в том числе анализ количества просмотров/контроллеров для MVC).

Это только небольшие приложения, которые вы можете объединить на основе ваших догадок и прошлого опыта.

Ответ 3

Если у вас есть фон в качестве разработчика веб-форм asp.net, ваш ответ естественный. Есть несколько вопросов, это зависит от точки зрения. Во-первых, с asp.net-mvc у нас нет полностью оборудованных серверных элементов управления, которые делают для нас многое, без реального осознания того, что они делают. Теперь вам нужно набрать больше кода и посмотреть, как хирург на html. Этот способ я могу найти разумный вопрос для "Взгляд Взрыва" Другие проекты следуют более или менее этой структуре, см. Проект Роба Конье: Mvc Storefront

PS: "Тощие контроллеры, жирная модель и... тупой взгляд"

[Обновить ответ на пояснения]

Mhh.. Я думаю, что нет никакого нарушения "немого взгляда". Важно то, что все взгляды не имеют ничего общего с кодом на уровне бизнес-логики или вашей модели. Вы можете нажать кнопку "Сохранить", контроллер должен знать, какое действие должно выполняться, вставлять или обновлять.

Ответ 4

В отношении большего размышления это то, о чем я думаю:
Объединение видов редактирования/создания будет простым на простых моделях, поскольку

- Те же свойства отображаемые
- Те же проверки

, но это приведет к тому, что

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

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