Доменный объект в представлениях

Question

Мы обсуждали, следует ли использовать доменные объекты в наших представлениях (asp.net mvc 2), или каждому представлению, для которого требуются данные, должна быть отправлена ​​модель представления?

Мне было интересно, есть ли у кого-нибудь плюсы / минусы по этому вопросу, на которые они могли бы пролить свет?

Спасибо

Answer 1

Мне нравится отделять мои доменные объекты от моих представлений. Насколько мне известно, мои Доменные Объекты предназначены исключительно для представления Домена приложения, теперь как приложение отображается.

Уровень представления не должен содержать никакой доменной логики. Все, что они отображают, должно быть предварительно определено их контроллером. Идеальный способ гарантировать, что это всегда соблюдается, состоит в том, чтобы гарантировать, что представление получает только эти плоские ViewModels.

Я задавал аналогичный вопрос сам. Вот цитата из ответа, который я принял:

Я думаю, что есть заслуги имея другой дизайн в домен, чем на уровне представления. Так что концептуально вы на самом деле глядя на две разные модели, одна для доменного уровня и один для слой представления. Каждая из моделей оптимизирован для своих целей .

Если у меня есть доменные объекты для Customer> Sales> Dispatch Address, тогда я не хочу иметь дело с обходом объекта на мой взгляд. Я создаю модель плоского представления, которая содержит все свойства. При использовании превосходного проекта с открытым исходным кодом AutoMapper .

практически не требуется дополнительной работы по отображению в эту упрощенную модель представления / представления

Кроме того, зачем вам передавать весь объект домена обратно в представление, если вы можете создать оптимизированное представление этой модели?

Answer 2

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

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

Во втором приложении, где естьвсегда объект для использования здесь, там и где-то еще, есть десятки классов, которые выглядят одинаково, делают то же самое, и множество кода преобразования между различными версиями одних и тех же объектов.Еще хуже то, что некоторые разработчики используют некоторую логику для «этой версии» класса, а другая логика - для «этой версии».Развитие очень болезненно и требует много испытаний потом.Изменение простой вещи требует большого внимания и большого количества кода, который необходимо изменить.Мне действительно не нравится это приложение для этого, потому что я никогда не видел бизнес-преимущества от этого подхода, по крайней мере, в прошлом году (и мы находимся в стадии производства с года).Это приложение в три-четыре раза дороже в разработке и обслуживании, чем первое.

Итак, мой забавный ответ на вопрос: это зависит.Если вы работаете в команде из 10-20 человек, вам нравится приходить на работу, пить немного кофе, разговаривать с другом, делать несколько простых вещей и идти домой, много промежуточных объектов и код преобразования будут полезны для вас.Если ваша цель - быть быстрой и дешевой, если вы хотите сосредоточиться на бизнес-уровне, новых функциях, быстрых изменениях и т. Д., Если вы касаетесь программного обеспечения и хотите заработать деньги на своем проекте (мы делаем все это, чтобы окончательно продать,верно?), второй подход был бы, вероятно, лучше.

Answer 3

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

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

Answer 4

Это зависит. В некоторых случаях будет хорошо использовать экземпляры классов моделей. В других случаях лучше использовать отдельную ViewModel. По моему опыту, вполне приемлемо иметь разные модели в вашем домене и в ваших взглядах. Или использовать модель домена в представлении. Делай то, что лучше для тебя. Сделайте шип для каждого варианта, посмотрите, что работает, а затем решите. Вы даже можете выбрать разные опции для каждого вида (и / или частично).

Answer 5

Если вы используете NHibernate или подобное - ваши доменные объекты, скорее всего, будут прокси-серверами, сериализуя эту работу. Вы всегда должны использовать ViewModel и отображать ваши доменные объекты в DTO внутри вашей viewmodel. Не используйте ярлыки здесь. Установление соглашения облегчит боль, которую вы будете испытывать позже.

Это стандартный шаблон по причине.

ш: //