Заменяет ли Resource in Spring HATEOAS DTO?
Я создаю REST API весной. Так что до сих пор у меня есть только сервисы чтения (GET). Для этого я использовал Spring HATEOAS, чтобы добавить ссылки, ссылающиеся на дочерние элементы.
Теперь я хочу добавить немного написания REST-Services. Обычно DTO используются в REST-сервисах, а затем сопоставляются с моделью предметной области.
Итак, мой вопрос: можем ли мы просто использовать ресурсы Spring HATEOAS, как в примере ниже, и обойтись без DTO? Или ресурсы предназначены для чего-то другого, и мне все еще нужны DTO?
@PostMapping
public ResponseEntity<String> saveProduct(@RequestBody ProductResource product) {
...
}
Ответы 1
Я бы сказал, что Spring HATEOAS не заменяет DTO: он строится поверх DTO. Таким образом, вы можете сделать свой класс DTO расширением ResourceSupport или обернуть его Resource<T>.
Начиная с Spring HATEOAS 1.0.0, выпущенного в конце сентября 2019 года, ResourceSupport и Resource<T> были переименованы в RepresentationModel и EntityModel<T> соответственно. Цитируя документация:
Representation models
The
ResourceSupport/Resource/Resources/PagedResourcesgroup of classes never really felt appropriately named. After all, these types do not actually manifest resources but rather representation models that can be enriched with hypermedia information and affordances. Here’s how new names map to the old ones:
ResourceSupportis nowRepresentationModelResourceis nowEntityModelResourcesis nowCollectionModelPagedResourcesis nowPagedModel
Однако важно, чтобы модель предметной области была отделена от модели API.
Модели, представляющие домен вашего приложения, и модели, представляющие данные, обрабатываемые вашим API, являются (или, по крайней мере, должны быть) разные заботы. Вы не хотите нарушать работу своих клиентов API, когда добавляете, удаляете или переименовываете поле из модели предметной области приложения.
В то время как ваш сервисный уровень работает с моделями домена/постоянства, ваши контроллеры API должны работать с другим набором моделей. Например, по мере развития ваших моделей домена/постоянства для поддержки новых бизнес-требований вы можете захотеть создать новые версии моделей API для поддержки этих изменений. Вы также можете отменить поддержку старых версий вашего API по мере выпуска новых версий. И это вполне возможно достичь, когда вещи разделены.
Чтобы свести к минимуму шаблонный код преобразования модели предметной области в модель API (и наоборот), вы можете полагаться на такие фреймворки, как MapStruct. И вы также можете рассмотреть возможность использования Ломбок для создания геттеров, сеттеров, equals(), hashcode() и toString() методов для вас.
@hakson Насколько я понимаю, у вас есть два класса: Product (модель предметной области) и ProductResource (это DTO, представляющий модель, обрабатываемую вашим API). Таким образом, вам могут не понадобиться другие модели.
У меня уже есть ProductResource, расширяющий ResourceSupport. Вы имеете в виду, что мне нужен дополнительный класс DTO или достаточно использовать ProductResource?