Подтвердить что ты не робот

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

Я знаю, что это, вероятно, вековой вопрос, но какова лучшая практика? Использование объекта модели домена на всех уровнях вашего приложения и даже привязка значений непосредственно к ним в JSP (я использую JSF). Или преобразовать объект модели домена в DTO на уровне DAO или Service и отправить легкий DTO на уровень представления.

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

Я должен отметить, что мое приложение использует Hibernate Model Objects и использует свои собственные объекты модели, созданные пользователем (что не связано с какой-либо сессией БД, всегда отделяется). Является ли любой из вышеперечисленных сценариев более полезным для строгой модели объекта модели? Использование Hibernate было огромным PITA в отношении таких вещей, как Lazy Initialization Exceptions.

Я редактирую этот вопрос в надежде на продолжение обсуждения (не уверен, что я делаю это правильно):

Проблема с объектами модели заключается в том, что они не являются гибкими вообще. В приведенном ниже комментарии говорится, что приложение должно быть спроектировано таким образом, чтобы объекты модели могли использоваться на всех уровнях. Зачем? Если пользователь хочет кусочек смешной функциональности, я должен сказать им: "Хорошо, что не будет работать с объектами модели"?

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

public class Teacher {
    List<Student> students;
    [tons of other Teacher-related fields]
}
public class Student {
    double gpa;
   [tons of other Student-related fields]
}

но, возможно, вам не нужна вся эта информация. Вам просто нужна фамилия преподавателя, количество учеников, которых они учат в этом году, и средний показатель по ГПД для всех студентов. Что бы вы сделали в этом случае? Получите полную информацию о преподавателях и студенческих отношениях, а затем ваш код получает счет в списке учеников, а затем вычисляет общее среднее значение всех gp внутри? Это похоже на waaaay больше усилий, чем просто создание DTO с "String lastName", "int numStudents" и "double combinationGpa;

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

4b9b3361

Ответ 1

Это действительно зависит от сложности вашего приложения. Смешивание объектов домена в слой представления имеет два возможных значения:

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

Если ваши объекты домена просты, а ваших просмотров мало, пропуская DTO, возможно, самое простое.

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

Ответ 2

Еще одно голосование за объекты домена. Что касается управления Driven Driven Design, то модель домена является королем и должна использоваться там, где это возможно. Приложение должно быть спроектировано таким образом, чтобы большинство слоев (слой инфраструктуры инфраструктуры) могли использовать объекты домена.

Я думаю, что DTO полезны только там, где объекты должны быть сериализованы. Если нет передачи по проводу или в несовместимую архитектуру, я бы не использовал их. Образец DTO полезен для сохранения сериализации вне объекта домена. Учитывая, что взаимодействие с UI/Domain не требует сериализации, простота и использование реальных объектов.

Ответ 3

Я думаю, что DTO обычно не является анти-шаблоном. Есть много людей и систем, использующих их, и преимущество, которое вы получаете, - это развязанный слой, который может быть спроектирован и модулизован независимо от модели домена. Хотя я согласен с тем, что вы должны использовать объекты домена, где это возможно, есть сценарии, в которых вы можете столкнуться с проблемами при привязке уровня представления непосредственно к модели домена.

Я отлично поработал с моделью просмотра, которая только обертывает объекты домена и делегирует большую часть операций им. Это разграничивает представление и уровень домена, позволяет гибко настраивать объекты домена и по-прежнему не так много работать для реализации поскольку IDE поддерживают шаблон делегирования.

Ответ 4

Сценарии, когда объект домена задают проблему:

  • вам может понадобиться агрегированная информация или другие типы "вычисленных полей", отправленных на уровень пользовательского интерфейса (в примере Flex/GWT), и не хотите испортить объект домена
  • вы можете столкнуться с необходимостью сериализации циклического графа объектов (в вашем примере, если у Student было отношение List), некоторые протоколы имеют проблемы с этим
  • Hibernate LazyInitializationException при работе с сериализаторами рамки (blazeDS для сериализатора Flex/GWT)

Я не уверен, что это четкий ответ в этих условиях

Ответ 5

По моему мнению, нет проблем с использованием объектов модели домена на каждом уровне. Вы сказали, что вам не нужна вся информация. Когда вы находитесь в JSP, используйте только те данные, которые вам нужны. Никто не заставляет вас получать каждое имущество. Вы также сказали, что вам нужно сделать вычисления, связанные с свойствами объекта, чтобы получить GPA, # студентов и т.д. У вас есть 3 варианта: создание синтетических свойств в объекте модели домена, которые возвращают нужные вам данные, завершают приятные и аккуратный; выполнять вычисления либо на уровне контроллера, либо на сервисе, и выставлять их через соответствующие геттеры; или обрабатывать все это внутри вашего JSP. Вам нужно получить/скомпилировать/прервать данные ANYWAY, поэтому зачем добавлять дополнительную сложность с помощью DTO.

Кроме того, с каждым DTO вы создаете.) дополнительный класс, который вы теперь должны поддерживать, и b.) в LEAST 1 дополнительном методе где-то в каком-то классе, который создает и заполняет DTO (DAO, factory метод и т.д.). Больше обслуживания = несчастный разработчик через 6 месяцев.

Итак, есть мои аргументы против DTO. Я использую их, но только в определенных сценариях, например, когда мне действительно нужно оптимизировать скорость и/или использование памяти, а стоимость увлажнения объекта полной модели домена слишком велика. Веб-сервисы - хороший пример того, когда я предпочитаю использовать DTO.

Ответ 6

Поведение класса или его внутренних методов не должно подвергаться воздействию слоев, не связанных с их поведением. Передавайте данные, а не поведение. Использовать объекты домена в домене. Веб-сайт не является контролируемым доменом, и разработчикам пользовательского интерфейса не нужно беспокоиться о поведении домена, просто данных.

Домен должен быть инкапсулирован и защищен от изменения кем-либо, не связанным со здоровьем домена.

Утечка поведения - не самая лучшая привычка.

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

Ответ 7

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

С другой стороны, я думаю, что очень мало вещей, которые вы обычно не должны делать. Те, кто говорит, что все DTO - злые, ошибаются - это всегда зависит от случая использования! Действительно ли они оправданы?

И, наконец, я лично считаю, что объекты домена следует отпустить на представление. Представьте, что такое интеграция калитки. Но возьмите Spring MVC, например - домен останется на уровне приложения, вероятно...

Ответ 8

В настоящее время DTO широко считается анти-паттерном, и совет обычно "избегает их любой ценой".

Одним из основных преимуществ структуры ORM, такой как Hibernate, является то, что вы можете использовать объекты домена на всех уровнях и не нуждаться в DTO. Предостережение, конечно, состоит в том, что вы должны посвятить когда-нибудь ДУМАТЬ эти отношения: когда использовать ленивую выборку, когда использовать нетерпение и т.д.