ASP.Net MVC Просмотр структуры

Question

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

Однако мне любопытно узнать о его структуре сайта:

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

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

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

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

Спасибо!

[Редактировать для уточнения]

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

В этом случае, будет ли нарушение правила «тупого представления» при использовании одного и того же представления для обработки обоих случаев вызывать серьезные проблемы?

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

НО это заставит вас либо

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

Answer 4

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

PS: «Тощие контроллеры, Fat Model и… тупой вид»

[Обновить ответ на уточнение]

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