Domain Object in Views
We've been having a discussion at work about whether to use Domain Objects in our views (asp.net mvc 2) or should every view that requires data be sent a ViewModel?
I was wondering if anyone had any pros/cons on this subject that they could shed some light on?
Thank you
4 ответа
Мне нравится отделять объекты домена от представлений. Насколько мне известно, мои объекты домена предназначены исключительно для представления домена приложения, теперь как приложение отображается.
Уровень представления не должен содержать никакой логики предметной области. Все, что они отображают, должно быть предварительно определено их Контроллером.Идеальный способ гарантировать, что это всегда соблюдается, - гарантировать, что представление принимает только эти сглаженные ViewModels.
Я сам задал аналогичный вопрос . Вот цитата из ответа, который я принял:
Я думаю, что есть свои достоинства имея другой дизайн в домена, чем на уровне представления. Итак, концептуально вы на самом деле глядя на две разные модели, одну для доменного слоя и один для презентационный слой. Каждая из моделей оптимизирован для их целей .
Если у меня есть объекты домена для Клиент > Продажи > Адрес отправки , то я не хочу иметь дело с обходом объекта в мой взгляд. Я создаю плоскую модель представления, которая содержит все свойства. Если вы используете отличный проект с открытым исходным кодом AutoMapper , почти не требуется дополнительной работы по сопоставлению с этой плоской моделью представления / представления.
Кроме того, зачем вам передавать весь объект домена обратно в представление, если вы можете создать оптимизированное представление этой модели?
Если вы используете NHibernate или подобное - ваши доменные объекты, скорее всего, будут прокси, сериализация этих объектов не работает. Вы всегда должны использовать ViewModel и отображать ваши доменные объекты на DTO в вашей модели представления. Не используйте короткие пути. Установка соглашения облегчит боль, которую вы испытаете позже.
Это стандартный шаблон не просто так.
w://
Определенно будут простые небольшие приложения, в которых можно использовать одни и те же модели на всех уровнях. Обычно небольшие формы поверх приложений с данными. Но для правильной предметной области мои мысли по этому поводу состоят в том, чтобы держать модели предметной области и модели представления отдельно, потому что вы не хотите, чтобы они когда-либо влияли друг на друга при изменении.
Если логика предметной области нуждается в небольшом изменении для обработки некоторой новой бизнес-логики на бэкенде, вы не должны рисковать, что это изменит ваше представление. И наоборот, если маркетолог или кто-то хочет внести изменения в представление, вы не хотите, чтобы эти изменения просачивались обратно в ваш домен (необходимость заполнять поля и поддерживать данные ни для каких других целей, кроме как какое-то представление, которое где-то собирается их использовать).
Это зависит от обстоятельств. В некоторых случаях можно использовать экземпляры классов моделей. В других случаях лучше использовать отдельную ViewModel. По моему опыту, вполне допустимо иметь разные модели в вашем домене и в ваших представлениях. Или использовать модель предметной области в представлении. Делайте то, что лучше всего работает для вас. Сделайте всплеск для каждого варианта, посмотрите, что работает, а затем решите. Вы даже можете выбрать другой вариант для каждого представления (и/или частичного).