dto или объект доменной модели на уровне представления?

<p>я знаю, что это, вероятно, извечный вопрос, но что лучше? использование объекта модели предметной области во всех слоях вашего приложения и даже привязка значений непосредственно к ним в jsp (я использую jsf). или преобразуйте объект модели домена в dto на уровне dao или service и отправьте облегченный dto на уровень представления.</p><p>мне сказали, что нет смысла использовать dto, потому что изменения в базе данных приведут к изменениям во всех ваших dto, тогда как повсеместное использование объектов модели просто потребует изменений в затронутом объекте модели. тем не менее, простота использования и легкий характер dto, кажется, перевешивают это.</p><p>я должен отметить, что мое приложение использует объекты модели hibernate и использует свои собственные объекты модели, созданные пользователем (то есть не привязанный к какому-либо сеансу бд, всегда отключенный). является ли какой-либо из приведенных выше сценариев более полезным для строгого шаблона объекта модели? использование hibernate было огромной pita в отношении таких вещей, как исключения lazy initialization.</p><p><strong> я редактирую этот вопрос в надежде на продолжение обсуждения (не уверен, правильно ли я делаю): </strong></p><p>проблема, с которой я сталкиваюсь с модельными объектами, заключается в том, что они совсем не гибкие. комментарий ниже говорит о том, что приложение должно быть спроектировано так, чтобы объекты модели могли использоваться на всех уровнях. зачем? если пользователь хочет кусок нелепой функциональности, я должен сказать им: «ну, это не будет работать с модельными объектами»?</p><p>просто и просто, бывают моменты, когда объекты модели не будут работать. ты можешь иметь:</p><pre><code>public class teacher { list<student> students; [tons of other teacher-related fields] } public class student { double gpa; [tons of other student-related fields] } </code></pre><p>но, возможно, вам не нужна вся эта информация. вам просто нужны фамилия учителя, количество учеников, которых они обучают в этом году, и средний средний балл для всех учеников вместе взятых. что бы вы сделали в этом случае? получите полную информацию об учителе и взаимоотношениях со студентами, а затем ваш код получит счет в списке студентов, а затем вычислит общее среднее значение всех gpas внутри? это похоже на большие усилия, чем просто создание dto с «string lastname», «int numstudents» и «двойной комбинированный gpa;</p><p>может показаться, что мое мнение об этом решено, но мне еще предстоит поработать в приложении, где объекты модели могут быть полностью использованы в каждом случае. обычные реальные приложения с необычными требованиями пользователей просто не работают таким образом.</p>

<p>это действительно зависит от сложности вашего приложения. смешивание доменных объектов в слой представления имеет два возможных значения:</p><ol> <li>вы будете испытывать желание изменить свой объект домена, чтобы приспособить вещи, которые вам нужны в слое представления</li> <li>слой view будет содержать дополнительную сложность, вызванную несоответствием между тем, что предлагают ваши доменные объекты, и тем, что действительно нужно вашему представлению. возможно, вы не сможете обойти эту сложность, но она, вероятно, не относится к слою view.</li> </ol><p>если ваши доменные объекты просты и у вас мало просмотров, пропустить dto может быть самой простой вещью. </p><p>с другой стороны, если ваша модель предметной области, вероятно, будет развиваться и становиться сложной, и если ваши представления могут быть многочисленными и разнообразными, то представление о конкретных объектах может быть хорошей идеей. в мире mvc использование viewmodels является обычным делом и имеет для меня большой смысл.</p>

<p>еще один голос за доменные объекты. что касается доменного дизайна, доменная модель является королем и должна использоваться там, где это возможно. приложение должно быть спроектировано таким образом, чтобы большинство слоев (слой инфраструктуры) могли использовать доменные объекты.</p><p>я считаю dto полезными только там, где объекты должны быть сериализованы. если нет передачи по проводам или в несовместимую архитектуру, я бы их не использовал. шаблон dto полезен для предотвращения сериализации вне доменного объекта. учитывая, что взаимодействие между пользовательским интерфейсом и доменом не требует сериализации, сохраняйте его простым и используйте реальные объекты.</p>

<p>я думаю, что dto - это не анти паттерн. есть много людей и систем, использующих их, и вы получаете выгоду от разделенного слоя представления, который может быть спроектирован и модульный независимо от модели предметной области. хотя я согласен с тем, что вам следует использовать доменные объекты, где это возможно, существуют сценарии, в которых могут возникнуть проблемы, когда вы привязываете слой представления непосредственно к модели домена.</p><p>я получил хороший опыт работы с моделью представления, которая охватывает только объекты домена и делегирует им большинство операций. это позволяет отделить представление и уровень домена, обеспечивает гибкую композицию объектов домена и по-прежнему не требует много усилий для реализации, поскольку ide поддерживают шаблон делегирования.</p>

<p>на мой взгляд, нет никаких проблем с использованием объектов модели предметной области в каждом слое. вы сказали, что вам не нужна вся информация. когда вы находитесь в jsp, используйте только те данные, которые вам нужны. никто не заставляет вас забирать каждую собственность. вы также сказали, что вам нужно делать расчеты, связанные со свойствами объекта, чтобы получить средний балл, количество учеников и т.д. у вас есть 3 варианта: создать синтетические свойства в вашем объекте модели домена, которые возвращают нужные вам данные, упакованные в nice и аккуратный; выполнять вычисления на уровне контроллера или службы и выставлять их через соответствующие методы получения; или обрабатывать все это внутри вашего jsp. вы должны извлекать/компилировать/обрабатывать данные в любом случае, так зачем добавлять больше сложности с dto.</p><p>кроме того, с каждым dto вы создаете.) дополнительный класс, который вам теперь нужно поддерживать, и b.) в дополнительном методе least 1 где-то в некотором классе, который создает и заполняет dto (dao, фабричный метод и т.д.) , больше обслуживания = несчастный разработчик 6 месяцев спустя.</p><p>итак, у меня есть аргументы против dto. я использую их, но только в определенных сценариях, например, когда мне действительно нужно оптимизировать скорость и/или использование памяти, а стоимость увлажнения объекта модели полного домена слишком велика. веб-сервисы являются хорошим примером того, когда я предпочитаю использовать dto.</p>

<p>сценарии, когда domain object проблематично отправлять:</p><ol> <li>вам может потребоваться агрегированная информация или другие типы «вычисляемых полей», отправленные на уровень пользовательского интерфейса (например, flex/gwt), и вы не хотите путать объект домена</li> <li>вы можете столкнуться с необходимостью сериализации графа циклических объектов (в вашем примере, если у ученика было отношение list), некоторые протоколы имеют проблемы с этим</li> <li>hibernate lazyinitializationexception при работе с сериализаторами фреймворка (blazeds для сериализатора flex/gwt)</li> </ol><p>я не уверен, что это ясный ответ в этих обстоятельствах</p>

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