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

Question

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

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

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

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

Answer 1

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

由于春季HATEOAS 1.0.0，发布于九月下旬2019年，ResourceSupport并Resource<T>已更名为RepresentationModel和EntityModel<T>分别。引用文档：

表示模型

在ResourceSupport/ Resource/ Resources/PagedResources组类从来没有真正感受到适当命名。毕竟，这些类型实际上并没有体现资源，而是体现了可以用超媒体信息和可供性丰富的表示模型。以下是新名称映射到旧名称的方式：

• ResourceSupport 就是现在 RepresentationModel
• Resource 就是现在 EntityModel
• Resources 就是现在 CollectionModel
• PagedResources 就是现在 PagedModel

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

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

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

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