JPA Entities и / против DTO

Question

Какова общая идея помочь решить, когда использовать DTO и когда использовать Entity в этих случаях?

1. Пользовательский интерфейс / серверная часть java, вызывающая сервисы. Должны ли они получать / отправлять объекты или DTO?
2. Веб-сервис, вызывающий сервисы. Должны ли службы принимать организации или DTO?

Мне нравится читать код, который передает сущности:

1. проще проходить, нет необходимости сопоставлять с DTO
2. не нужны дополнительные классы
3. отношения с другими объектами уже определены, поэтому нет необходимости объединять связанные DTO в один DTO
4. просто POJOs

Но есть аргументы в отношении DTO, которые сопоставляют сущность более безопасно, потому что это контракт, и сущность может измениться на любую форму, и DTO останется прежним. Например, как у сущности есть имя поля, так и у DTO также есть имя поля. Позже, если требование изменится, таблица базы данных изменится, сущность также может измениться, сменив имя на firstName и lastName. Но DTO по-прежнему будет иметь имя поля, которое firstName + lastName.

Итак, вот список плюсов использования DTO:

1. обратно совместимый с точки зрения кода, который принимает DTO

Минусы DTO, о которых я могу подумать:

1. необходимо определить классы DTO и отображение (возможно, с помощью dozer)
2. программистам придется анализировать, когда использовать DTO и сущность, я имею в виду, что передача DTO для каждого метода - беспорядок
3. накладные расходы на преобразование сущностей в DTO и наоборот
4. Я все еще не уверен насчет отношений один-ко-многим, как их сопоставить. В JPA мы можем лениво инициализировать это, но при переходе в DTO, должен ли я инициализировать это или нет. Вкратце, DTO не могут иметь ленивые инициализированные прокси, только содержат значения.

Пожалуйста, поделитесь своими мыслями ..

Спасибо!

Вот несколько цитат из разных мест

pro dto :

Повторное использование класса сущности в качестве DTO кажется грязным Публичный API класс (включая аннотации на публику методы) более четко не определяет цель договора это Предъявление. Класс закончится с методы, которые актуальны только тогда, когда класс используется как DTO и некоторые методы, которые будут только актуально, когда используется класс как сущность. Опасений не будет чисто разделены и все будет более тесно связаны. Для меня это более важное соображение дизайна затем пытается сэкономить на количестве файлы классов созданы.

pro entity :

Абсолютно НЕТ !!!

объекты JPA отображаются в базу данных, но они не привязаны к базе данных. Если база данных меняется, вы меняете сопоставления, а не объекты. объекты остаются прежними. Это Весь смысл!

Answer 1

Я бы выбрал вариант DTO по следующим причинам:

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

Answer 2

Pro DTO: 1. Интерфейс пользователя в большинстве случаев требует определенных свойств, которые предназначены только для передачи аргументов, отображающих состояние интерфейса. Это состояние не требуется для сохранения, следовательно, не требуется для использования на объектах.
2. Бизнес-логика должна быть внутри сущностей или во вспомогательных классах для сущностей. Вы не должны делиться этим с пользовательским интерфейсом / уровнем представления или с вызывающим его клиентом.
3. Изменение в организациях иногда не требует изменения в DTO и наоборот.
4. Проще выполнить проверки на системном уровне в DTO в службах пользовательского интерфейса, следовательно, останавливать вызов в бизнес-службах, когда это не нужно.
5. Вы можете свободно внедрять / использовать другие структуры проверки, когда сторона пользовательского интерфейса получает DTO, а не объект, заполненный данными, поступающими из пользовательского интерфейса.
6. Слой интерфейса / презентации слабо связан.

Вот пример потока при использовании DTO:
Пользовательский интерфейс -> MVC -> Проверка системы с использованием служб пользовательского интерфейса -> Business Delegate -> Business Services -> Persist.