MVC: модели данных и модели представления

Question

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

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

Что делает наличие отдельной модели для двух проблем стоящей проблемой дублирования и отображения кода?

Answer 1

В основе двух моделей лежит разделение проблем. Я хочу, чтобы мой вид работал от одной модели. Я хочу, чтобы моя модель предметной области представляла концептуальную модель, которую я строю с помощью экспертов по предметной области. ViewModel часто имеет технические ограничения. Модель предметной области относится к POCO и не связана техническими ограничениями ни показанных данных (Просмотр), ни постоянных (в БД или иным образом).

Предположим, у меня есть три объекта, показанные на экране. Значит ли это, что мне нужно навязать отношения между тремя? Или просто создайте объект компонента ViewModel, который содержит все три элемента. С отдельной ViewModel проблемы View отделены от моего домена.

Answer 2

почему? потому что у представления не должно быть возможности использовать объект модели!

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

Поэтому всегда передайте только данные, необходимые для представления, вместо объекта с методами.

Answer 3

J.P. Статья Boodhoo DTO с привязкой к экрану поможет вам понять преимущества дизайна.

Существует также преимущество безопасности , о котором я написал.

Наличие модели презентации упрощает ваши взгляды. Это особенно важно, потому что представления, как правило, очень трудно проверить. Имея модель представления, вы перемещаете большую часть работы из представления в модель домена-> представления. Такие вещи, как форматирование, обработка нулевых значений и выравнивание графов объектов.

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

Answer 4

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

Answer 5

Кажется, у меня есть дублирование правил.

т. проверка клиентского объекта в пользовательском интерфейсе, затем сопоставление с объектом домена, который должен быть проверен.

Однако я склоняюсь к тому, чтобы сопоставить мой набор доменных объектов для создания модели - т.е. веб-страница, которая показывает информацию о клиенте, информацию об акциях и т. д. ... моя модель становится структурой, которая содержит объект Customer и объект Stock.

CompanyPageModel

публичный клиент Customer {get;} публичные акции Stock {get;}

тогда в моем проекте MVC ViewData.Model.Customer.Name ViewData.Model.Stock.CurrentStocks

Разделение кажется более трудоемким, но позже хорошо иметь такое разделение модели UI / Domain ... вроде как написание тестов:)

Answer 6

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

Answer 7

Наконец-то я выпил классного помощника, мне нравится, когда я могу пометить свою модель представления с инструкциями на дисплее и автоматически подключить ее.

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