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

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

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

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

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

CompanyPageModel

Клиент публичного клиента {get;} публичный запас акций {get;}

то в моем проекте mvc ViewData.Model.Customer.Name ViewData.Model.Stock.CurrentStocks

Разделение "похоже" больше похоже на работу, но потом хорошо иметь это разделение модели UI/Domain... sorta like writing tests:)

Ответ 7

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

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