Каков хороший шаблон для преобразования между объектами гибернации и объектами передачи данных?

Question

У меня были похожие вопросы и проблемы относительно того, как конвертировать между объектами Hibernate и объектами передачи данных, возвращаемыми веб-службой, как обсуждалось в этом вопросе:

Использование объектов передачи данных в ejb3 считается лучшей практикой

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

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

Есть ли хороший шаблон проектирования, который я могу использовать для преобразования объекта Hibernate (который реализует интерфейс) в DTO, который реализует тот же интерфейс?

Таким образом, предполагая, что оба из следующих объектов реализуют 'Book', мне нужно будет преобразовать BookEntity.class в BookDTO.class, чтобы я мог позволить JAXB сериализоваться и возвращаться.

Опять же, вся эта перспектива кажется мне сомнительной, но если есть хорошие способы помочь справиться с этим обращением, я бы хотел получить некоторое представление.

Возможно, есть какой-нибудь интересный способ конвертации с помощью отражения? Или шаблон «строителя», о котором я не думаю?

Должен ли я просто игнорировать шаблон DTO и обмениваться сущностями?

Answer 1

Должен ли я просто игнорировать шаблон DTO и передать сущности вокруг?

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

Первоначальной причиной паттерна DTO была чрезмерная болтливость в приложениях EJB 1.0 и 2.0 при передаче EJB-сущностей сущностей на уровень представления. Решение состояло в том, чтобы поместить объект EJB в DTO.

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

Я бы сказал, что DTO - это шаблон Core J2EE, который стал анти-шаблоном.

Я понимаю, что некоторые люди не согласны. Я просто предлагаю свое мнение. Это не единственный способ сделать это, и не обязательно «правильный» способ. Это мое предпочтение.

Answer 2

Должно быть противоположное мнение среди всех веселых ударов DTO.

tl; dr - иногда все еще полезно.

Преимущество DTO заключается в том, что вам не нужно добавлять миллионы аннотаций к классам вашего домена.

Вы начинаете с @Entity. Не так плохо. Но тогда вам нужен JAXB, чтобы вы добавили @XMLElement и т. Д. - а затем вам нужен JSON, чтобы вы добавили такие вещи, как @JsonManagedReference для Джексона, чтобы они правильно делали отношения, затем добавляли и т. Д.

Довольно скоро твой POJO уже не так прост. Когда-нибудь почитайте о «доменном дизайне».

Кроме того, вы можете «фильтровать» некоторые свойства, о которых представление не должно знать.

Answer 3

Мы не должны забывать, что объекты сущностей не легко обрабатывать, когда они находятся в управляемом состоянии. Это делает их переход к формам GUI проблематичным. Чтобы быть более точным, дочерние объекты обрабатываются с нетерпением. Это не может быть сделано вне сессии, исключая случаи. Таким образом, они либо должны быть выселены (отделены) от менеджера организации, либо должны быть преобразованы в соответствующие DTO. Если, конечно, не существует шаблона, о котором я не знаю, я был бы очень рад узнать.

Answer 4

Для быстрого создания «похожего» DTO без набора дубликатов кода get / set вы можете использовать BeanUtils.copyProperties . Эта функция поможет вам быстро скопировать данные из DAO в класс DTO. Просто помните, что существует несколько общих библиотек, поддерживающих BeanUtils.copyProperties, но их синтаксис не одинаков.

Answer 5

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

В нашем проекте есть POJO с аннотациями JAXB, которые отделены от POJO с аннотациями JPA.Наша команда обсуждала, как лучше всего перемещать данные между двумя объектами (фактически структурами данных).

Вот вариант для людей, чтобы рассмотреть:

Мы нашли и экспериментируем с Dozer, который обрабатывает (1) одно и то же имя, (2) сопоставление XML и (3) пользовательские преобразования как способы копирования данных между двумя POJO.

До сих пор им было очень легко пользоваться.