Должны ли ресурсы JAX-RS напрямую создавать объекты JPA? [Дубликат]

Я использую DTO.

Мне не нравятся недостатки, но кажется, что другие варианты еще хуже:

Экспозиция объектов домена может привести к проблемам безопасности и утечки данных. Аннотации Джексона, похоже, могут решить проблему, но слишком легко совершить ошибку и выставить данные, которые не следует раскрывать. При разработке класса DTO гораздо сложнее сделать такую ​​ошибку.

С другой стороны, недостатки подхода DTO могут быть уменьшены с помощью таких объектов, как сопоставление объектов с объектами, и Lombok для меньше плитки.

Почему вы должны использовать DTO в вашем REST API

DTO означает Объект передачи данных .

Этот шаблон был создан с очень четко определенной целью: передать данные на удаленные интерфейсы , так же как веб-службы . Этот шаблон очень хорошо подходит для REST API и DTO, что даст вам большую гибкость в конечном итоге.

Представления ресурсов REST не обязательно должны иметь те же атрибуты, что и настойчивость модели: вам может потребоваться пропустить, добавить или переименовать атрибуты.

Просто упомянем несколько преимуществ разоблачения DTO вместо моделей сохранения:

• DTO могут быть для ваших нужд, и они великолепны при экспонировании только набора атрибутов ваших объектов персистентности. Вам не понадобятся аннотации, такие как @XmlTransient и @JsonIgnore , чтобы избежать сериализации некоторых атрибутов.
• Используя DTO, вы будете избегайте аннота аннотаций в ваших объектах персистентности, т. е. ваши объекты персистентности не будут раздуты с аннотациями, не связанными с сохранением;
• У вас будет полный контроль над атрибутами, которые вы получаете при создании или обновлении ресурса;
• Если вы используете Swagger , вы можете использовать @ApiModel и @ApiModelProperty аннотации для документирования ваших моделей API без использования ваших сущностей persistence;
• Вы можете иметь разные DTO для каждой версии вашего API;
• У вас могут быть разные DTO для разных типов медиа;
• Ваши DTO могут иметь список ссылок для HATEOAS . Это то, что нельзя добавлять к объектам персистентности.

Картографические рамки

Вам не нужно будет сопоставлять ваши объекты персистентности с DTO и наоборот ручное ее закрытие . Существует множество схем отображения , которые вы можете использовать для этого. Например, посмотрите на MapStruct , который основан на аннотациях и работает как обработчик аннотации Maven. Он также работает в приложениях CDI и Spring.

Связано: Чтобы дать лучшие имена вашим классам DTO, обратитесь к этому ответу .

Когда ваш API является общедоступным, и вы должны поддерживать несколько версий, вы должны пойти с DTO.

С другой стороны, если это частный API и вы управляете как клиентом, так и сервером, я склонен пропустить DTO и выставить непосредственно доменную модель.

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

Это в основном относится к стороне ответа json / rest api. Я даже написал аддон Джексона, чтобы не писать много json-представлений / фильтров для этих случаев: https://github.com/Antibrumm/jackson-antpathfilter

С другой стороны, DTO являются хорошей вещью на стороне ввода запроса таких API. Например, работа с сущностями может быть довольно сложной с учетом двунаправленных отношений. Также вы действительно не хотите, чтобы вызывающий абонент модифицировал атрибут «создатель», например. Поэтому при сопоставлении таких запросов вам необходимо будет распутать определенные поля.