java - Spring HATEOAS 中的 Resource 是否取代了 DTO？

Question

我正在 Spring 中构建 REST API。所以直到现在我只有阅读服务(GET)。为此，我使用 Spring HATEOAS 添加引用子元素的链接。

现在我想添加一些写作 REST-Services。通常 DTO 用于 REST 服务，然后将它们映射到域模型。

所以我的问题是:我们可以像下面的例子一样使用 Spring HATEOAS 的资源而不使用 DTO 吗？或者资源是否用于其他用途而我仍然需要 DTO？

@PostMapping
public ResponseEntity<String> saveProduct(@RequestBody ProductResource product) {
  ...
}

Answer 1

我会说 Spring HATEOAS 不会取代 DTO:它建立在 DTO 之上。所以你可以让你的 DTO 类扩展 ResourceSupport 或用 Resource<T> 包裹它.

自 Spring HATEOAS 1.0.0 于 2019 年 9 月下旬发布以来， ResourceSupport 和 Resource<T> 已更名为 RepresentationModel 和 EntityModel<T> 分别。引用 documentation :

Representation models

The ResourceSupport / Resource / Resources / PagedResources group 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:

• ResourceSupport is now RepresentationModel
• Resource is now EntityModel
• Resources is now CollectionModel
• PagedResources is now PagedModel

然而，重要的是保持领域模型与 API 模型分离。

代表您的应用程序域的模型和代表您的 API 处理的数据的模型是(或至少应该是)不同的关注点。当您从应用程序域模型中添加、删除或重命名字段时，您不希望破坏 API 客户端。

当您的服务层在域/持久性模型上运行时，您的 API Controller 应该在一组不同的模型上运行。例如，随着您的域/持久性模型发展以支持新的业务需求，您可能希望创建新版本的 API 模型来支持这些更改。您可能还希望在发布新版本时弃用旧版本的 API。当事情解耦时，完全有可能实现。

为了最大限度地减少将领域模型转换为 API 模型(反之亦然)的样板代码，您可以依赖诸如 MapStruct 之类的框架。 .你也可以考虑使用 Lombok生成 getter、setter、 equals() , hashcode()和 toString()方法给你。