Мы обсуждали вопрос о том, следует ли использовать объекты домена в наших представлениях (asp.net mvc 2) или должно ли каждое представление, требующее отправки данных, ViewModel?Объект домена в представлениях
Мне было интересно, есть ли у кого-нибудь какие-либо плюсы и минусы на эту тему, чтобы они могли пролить свет?
Спасибо
Я хотел бы отделить мой домен объекты из моих соображений. Насколько мне известно, мои объекты домена предназначены исключительно для представления домена приложения, а теперь, как отображается приложение.
Уровень презентации не должен содержать никакой логики домена. Все, что они отображают, должно быть предварительно определено их контроллером. Идеальный способ обеспечить это всегда соблюдается, чтобы обеспечить, чтобы представление только получало эти сплющенные ViewModels.
Я сам спросил similar question. Вот цитата из ответа я принял:
Я думаю, что есть заслуги перед , имеющие различную конструкцию в домене , чем в уровне представления. Итак, концептуально вы на самом деле , глядя на две разные модели, один для домена и один для уровня презентации . Каждая из моделей оптимизирована для их использования.
Если у меня есть объекты домена для Customer>Sales>Dispatch Address, то я не хочу иметь дело с объектом обхода, на мой взгляд. Я создаю сплющенную модель представления, содержащую все свойства. Практически нет никакой дополнительной работы в сопоставлении с этой сплющенной моделью представления/презентации, если вы используете отличный проект с открытым исходным кодом AutoMapper.
Кроме того, почему вы хотите передать весь объект домена обратно в представление, если вы можете создать оптимизированное представление этой модели?
Если вы используете NHibernate или аналогичный - ваши объекты домена, скорее всего, будет прокси, сериализации эти серовато работы. Вы всегда должны использовать ViewModel и сопоставлять объекты своего домена с DTO в своей модели viewmodel. Не используйте ярлыки здесь. Установка соглашения облегчит боль, которую вы будете испытывать позже.
Это стандартный шаблон по причине.
ш: //
зависит от цели. В некоторых случаях будет хорошо использовать экземпляры классов моделей. В других случаях лучшим вариантом является отдельный ViewModel. По моему опыту вполне приемлемо иметь разные модели в вашем домене и в ваших представлениях. Или использовать модель домена в представлении. Делайте то, что лучше всего подходит для вас. Сделайте всплеск для каждого варианта, посмотрите, что работает, а затем решите. Вы можете выбрать другой вариант для каждого вида (и/или частичного).
Определенно будут простые небольшие приложения, где хорошо использовать одни и те же модели во всех слоях. Как правило, небольшие формы для приложений с данными. Но для правильной области мои мысли по этому вопросу состоят в том, чтобы сохранить модели домена и просматривать модели отдельно, потому что вы не хотите, чтобы они когда-либо влияли друг на друга при изменении.
Если логике домена требуется небольшое изменение для обработки новой бизнес-логики на задней панели, вы не хотите рисковать тем, что изменяете свое представление. И наоборот, если маркетинг или кто-то хочет внести изменения в представление, вы не хотите, чтобы эти изменения протекали обратно в ваш домен (чтобы заполнить поля и сохранить данные для каких-либо других целей, чем какое-либо представление, где-то будет использовать его).
В настоящее время у меня хорошее сравнение, потому что я работаю над двумя проектами, использующими разные подходы. Я далек от того, что «это плохо, и это хорошо», потому что это написано в некоторых шаблонах. Я знаю шаблоны, мне нравятся образцы, но я никогда не слепо следовать за ними, чтобы быть прав. Я всегда использую то, что мне нужно в настоящее время для достижения текущих целей.
В первом приложении, использующем объекты домена, разработка выполняется очень быстро. Немногие изменения в нескольких местах, и у вас есть дополнительные свойства, формы ввода и т. Д. Вы не беспокоитесь о слоях, просто расширяете/меняете код и переходите к другой проблеме.
Во втором приложении, где всегда есть объект для использования здесь, где-то еще, есть десятки классов, которые выглядят одинаково, делая то же самое и тонну кода преобразования между различными версиями одних и тех же объектов. Еще хуже то, что некоторые разработчики делают некоторую логику в «этой версии» класса, а другая логика делается на «этой версии». Развитие очень болезненно и требует много испытаний после этого. Изменение простой вещи требует большого внимания, и необходимо изменить код. Мне действительно не нравится это приложение для этого, потому что я никогда еще не видел выгоды для бизнеса от этого подхода, по крайней мере в течение прошлого года (и мы находимся на стадии производства с года). Это приложение в три-четыре раза дороже для разработки и обслуживания, чем первое.
Итак, мой смешной ответ на вопрос: это зависит. Если вы работаете в команде 10-20 человек, вам нравится приходить на работу, пить немного кофе, разговаривать с другом, делать несколько простых вещей и идти домой, много промежуточных объектов и код конвертации будут вам полезны. Если ваша цель - быть быстрой и дешевой, если вы хотите сосредоточиться на бизнес-слое, новых функциях, быстрых изменениях и т. Д., Если вы касаетесь бизнеса программного обеспечения и хотите наживать свой проект (мы делаем все это, чтобы быть окончательно проданным, правильно?), второй подход, вероятно, был бы лучше.
+1, но как насчет простых объектов домена, таких как категория, которые имеют только идентификатор и метку? Для некоторых приложений с большим количеством из них может стать довольно раздражающим создание MyEntity {Id, Label} и MyDto {Id, Label}, где единственным отличием является имя. – mathieu
@mathieu - Очевидно, вы можете использовать свое усмотрение, когда дело доходит до таких примеров :). Объекты домена, такие как ваш пример, не будут содержать логики домена, и поэтому это будет приемлемо. – GenericTypeTea
ОК, вот что я думал. если у вас есть время, вы могли бы взглянуть на это: http://stackoverflow.com/questions/3539108/asp-net-mvc-model-inheritance? Я не очень-то новичок в техническом материале asp.net mvc, но для «философского» и дизайна я мог бы использовать некоторые указатели! – mathieu