Должен ли я использовать DTO или доменные объекты в flex при подключении к blazeds / java / jpa с помощью удаленных сервисов?

Question

Я работаю над интерфейсом Adobe Flex с интерфейсом Java, использующим JPA для обеспечения устойчивости. Используемый протокол - это удаленные объекты (AMF), реализованные с помощью BlazeDS.

Я начал с DAO с сервис-фасадом и объектами, но без каких-либо конкретных DTO. Те же POJO, доменные объекты, были переданы в сервис-фасаде, а те, которые используются в качестве DTO, переданы в Dibers Hibernate.

Тем не менее, последние несколько дней я думал, является ли это хорошим подходом или нет. Последняя статья по теме, которую я прочитал, была такой: Интересный блог JPA Pattern

Ситуация: Скажем, у меня POJO Book с однонаправленным отношением ManyToOne к POJO Category (т.е. каждая книга может быть связана только с одной категорией, но одна и та же категория может быть связана со многими книгами). Я вижу несколько альтернатив:

Альтернатива 1: Я выставляю метод / операцию addUpdateBook(Book book). При реализации этой операции я добавляю / обновляю как книгу, так и указанную категорию. Я имею в виду, если клиент отправляет книгу с категорией, которой раньше не существовало, это означало бы, что клиент неявно может редактировать категории, используя операцию addUpdateBook.

• клиент работает напрямую с моделью домена!
• вся информация о категории будет отправлена ​​при добавлении новой книги даже если ссылка на категорию будет достаточной

Альтернатива 2: Я выставляю метод / операцию addUpdateBook(Book book,Long categoryId). В реализации я извлекаю категорию для данного categoryId и заменяю категорию, указанную в книге POJO, а затем сохраняю книгу. Другими словами, я игнорирую любую категорию в объекте книги, я просто смотрю на categoryId. Это означает, что клиент должен будет использовать другую операцию для изменения категории.

• pro: клиент все еще может работать более или менее на модели домена, но ...
• con: ... для клиента сбивает с толку, что категория книги объект будет игнорироваться
• con: вся информация о категории книги будет отправлена, даже если сервер никогда его не прочитает
• pro: может быть более понятно, когда следует использовать отдельную операцию для модификации категории
• con: мне нужно найти категорию, прежде чем сохранить книгу. я думаю, это означает некоторые накладные расходы.

Альтернатива 3: Я выставляю метод / операцию addUpdateBook(BookDTO bookDto). POJO BookDTO выглядит как POJO Book, но вместо поля Category category оно имеет поле Long categoryId. В реализации я извлекаю Category для данного categoryId, прежде чем сохранить Book.

• pro: не смущает клиента
• con (?): Что должен возвращать метод getBook(Long bookId)? если это вернуть только BookDTO? Тогда потребуется также вызвать операция getCategory(Long categoryId) для того, чтобы "весь Информация о книге ". Тогда клиент должен был бы установить вместе разные части в локальном домене представления книги. По сравнению с альтернативой 1 это было бы более сложным для клиента сторона
• con: мне нужно найти категорию, прежде чем сохранить книгу. я думаю, это означает некоторые накладные расходы.
• con: принудительное использование DTO в клиенте заставляет его работать с физическими деталями и делает его несколько далеким от реальной модели предметной области. Похоже, я упускаю из виду наличие доменной модели и использование JPA на бизнес-уровне.

Полагаю, (!) Альтернатива 3 - это способ разработки операций в контексте SOA. Однако для меня не так важно быть слабо связанным между клиентом и сервером. Моя задача не в том, чтобы обеспечить поддержку нескольких клиентских платформ.

Какую альтернативу вы бы предложили? Есть ли другие лучшие альтернативы? Знаете ли вы какие-нибудь полезные ресурсы, такие как примеры кода, которые могли бы мне помочь?

Answer 1

Я использую что-то, связанное с «Альтернативой 3».В начале я начал использовать доменные объекты (вероятно, также из-за моего опыта работы с dataservices ), через некоторое время я обнаружил слишком много проблем и переключился на DTO.Все службы публикации предоставляют только DTO (оба для параметров ввода / вывода).

Некоторые проблемы, с которыми я столкнулся при работе непосредственно с объектами домена и BlazeDS:

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

b) вам нужно использовать приемы, чтобы разрешить преобразование данных между клиентом / сервером.Например, с использованием строк вместо дат, чтобы предотвратить разницу часовых поясов.Или , используя строки вместо int / double.Вы можете решить некоторые из этих проблем, написав собственные прокси, но я все же думаю, что вместо других типов данных проще использовать строки.

c) в большинстве случаев вам не нужны все данные издоменные объекты, и для того, чтобы справиться с этим, вам нужно использовать различные платформы с поддержкой разбиения на страницы / отложенной реализации на клиенте.Эти рамки вносят сложность, и я стараюсь держаться подальше от этого.

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