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

Я знаю, что это - вероятно, старый вопрос, но какова лучшая практика? Используя объект модели предметной области всюду по всем слоям Вашего приложения, и даже обязательные значения непосредственно им на JSP (я использую JSF). Или преобразуйте объект модели предметной области в DTO в ДАО или Уровне служб и отправьте легкий DTO в уровень представления.

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

Я должен отметить, что мое использование приложения В спящем режиме Объекты модели, И использует его собственно созданные объекты модели (значение не связанный с любой сессией DB, всегда отсоединяемой). Имеет любой вышеупомянутые сценарии, более выгодные для строгого шаблона Объекта модели? Используя В спящем режиме, был огромный ЛАВАШ относительно вещей как Ленивые Исключения Инициализации.

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

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

Простой и простой, существуют только времена, когда объекты модели не будут работать. Вы можете иметь:

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

но возможно Вам не нужна вся та информация. Вам просто нужны фамилия учителя, число студента, которого они учат в этом году, и средний GPA для всех объединенных студентов. Что Вы сделали бы в этом случае? Получите полную информацию об учителе и студенческие отношения, и затем Ваш код получает количество в Списке Студентов, затем вычисляет общее среднее число всего gpas внутри? Это походит на waaaay больше усилия, чем простое создание DTO с 'Строкой lastName', 'интервал numStudents', и 'двойной combinedGpa;

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

49
задан Peter Majeed 21 August 2014 в 00:38
поделиться

3 ответа

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

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

-4
ответ дан 7 November 2019 в 11:55
поделиться

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

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

8
ответ дан 7 November 2019 в 11:55
поделиться

Сценарии, когда отправка объекта домена проблематична:

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

Я не уверен, что это однозначный ответ в данных обстоятельствах

2
ответ дан 7 November 2019 в 11:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: