В MVC (особенно в Asp.Net MVC) модель должна быть представлена ​​одним представлением?

Question

Мне кажется, это не имеет особого смысла, но после прочтения информации следующее:

http://weblogs.asp.net/scottgu/archive/2010/02/05/asp-net-mvc-2-release-candidate-2-now-available.aspx

http://bradwilson.typepad.com/blog/2010/01/input-validation-vs-model-validation-in-aspnet-mvc.html

http://blog.stevensanderson.com/2010/02/19/partial-validation-in-aspnet-mvc-2/#comment-35397( конкретно некоторые комментарии)

Похоже, что идея Asp.Net MVC заключается в том, что у вас есть взаимно-однозначные отношения между моделями и представлениями. Похоже, это идет вразрез с принципом СУХОЙ и некоторыми другими стандартными методами программирования.

Например, допустим, у вас есть модель учетной записи пользователя, и для ее редактирования доступны два представления: одно для самого пользователя, чтобы редактировать его, и одно для администратора сайта, чтобы редактировать его. Администратор имеет доступ к дополнительному полю для чего-то внутреннего, необходимого, но пользователь не может просматривать / редактировать его. В соответствии с функциональностью привязки модели и убеждениями, описанными в постах, упомянутых выше, мне нужно будет создать две отдельные пользовательские модели, по одной для каждой страницы, и единственным отличием будет это дополнительное поле. Это также простой пример, у меня есть несколько, которые я видел, где это могло бы означать 5 или 6 разных моделей для одного и того же объекта, только несколько полей, различающихся в каждом представлении. Это действительно не имеет никакого смысла для меня.

Answer 1

Я не читал упомянутые вами посты, но нет ничего плохого в том, чтобы иметь одну модель для пары просмотров.

Я бы просто использовал эту пользовательскую модель и использовал бы ее во всех представлениях, даже если есть некоторые поля, которые не используются.

Если все становится немного сложнее, но у пользователей все еще много общего, вы можете использовать агрегацию для пользовательской модели (User.Address) или использовать интерфейсы (у пользователя есть поля улица и город и реализуется IAddress).

Оба метода имеют свои плюсы и минусы - агрегация используется в большинстве ситуаций.

EDIT

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

Answer 2

Если вы используете аннотации, я бы настоятельно рекомендовал одну «модель» и несколько «моделей представления». Мы применили подход Viewmodel к нашему текущему приложению и пожинаем плоды, потому что наша базовая модель должна быть показана в нескольких разных видах.

Answer 3

TL; DR: создание множества моделей просмотра. Они дешевые и гибкие.

«Похоже, это противоречит принципу СУХОЙ и некоторым другим стандартным практикам программирования».

[Требуется цитата]?

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

Принципал DRY обычно относится к повторяющейся бизнес-логике. Повторение свойства FirstName в разделе экрана CRUD на самом деле не имеет большого значения. Даже 5-6 раз, что это? 40 секунд?

Если вы ошибочно принимаете свои модели представления за объектно-ориентированные классы, а не за гомоконистический экран представления, которые вы рискуете заполнить, будут всевозможными наследованиями или бизнес-логикой.

Вы на самом деле не программируете, когда делаете глупые определения вида. Эту работу можно легко выполнить в графическом интерфейсе Access или определить в XML. Тот факт, что ваши модели представления экрана в C # просто упрощают их заполнение данными и их доставку, а также работу с такими инструментами, как WCF и Automapper.

Answer 4

Нет официального требования иметь только одно представление для модели в ASP.NET MVC. Во многих случаях это привело бы к дублированию кода.

Мне лично нравится разделять зависимости вида модели, то есть одно представление на модель. Это сводится к тому, что вы никогда не знаете, как, скажем, пара очень похожих пар моделей и моделей будет развиваться в будущем. Если они раздельные, вы просто вносите изменения в одно, и вам не нужно «исправлять» другие представления, которые зависели от этой модели, или, что еще хуже, требовать дополнительной работы для создания собственных моделей для них всех сразу. 1003 *