REST开发后端DTO与前端DTO

如何解决REST开发后端DTO与前端DTO

就数据对象而言，开发（基于JSON的）REST服务时最好的方法是什么。

我应该从前端模型中拆分数据库模型（后端）吗？

始终将与数据库相关的JPA实体保持在特定的层上，然后将它们转换为一组用于前端的DTO是一种好习惯吗？

例如3层架构：

Controller

Service

Repository

我应该将DB实体（用JPA注释注释）限制在Repository和Service层

然后使Controller仅与另一组UI“实体”（DTO）一起使用吗？

这将需要在两种自动或“手动”之间进行映射。

这允许“瘦”的前端实体。

例如在后端中，我们仅具有JPA批注，并且拥有者是Account引用：

@Entity
public class Job {
    @Id
    @GeneratedValue(strategy = GenerationType.AUTO)
    private Long id;
    private String name;
    @ManyToOne(fetch = FetchType.LAZY)
    private Account owner;

但是在前端层中，我将具有Jackson特定的注释。我不需要整个Account对象，而只需要UI中的ID：

class Job {
 long id;
 String name;
 long ownerId;
}

更新 在尝试了“手动”映射之后，得出的结论是它很快就变得一团糟。

在我的情况下，我希望Repository层返回Entity（JPA），而Service层进行映射并返回Dto。因此，从DB中获取数据似乎很容易承受，仅涉及1个映射（从Entity到Dto）。但是，在创建/保存实体时，组合对象的问题更大。例如：

假设我从API客户端到POST UserDto一个UserProfileDto（其中包含Controller作为复合对象）。现在，Service层将接受UserDto，但必须找到与该UserProfileEntity相对应的UserProfileDto。

此外，存储库的.save()方法返回新保存的实体。现在，必须将此映射到Dto，然后再映射回Entity，如果我想将其进一步用作另一个对象的一部分（否则，我将得到object references an unsaved transient instance - save the transient instance before flushing错误）。

例如，如果我这样做：

repository.save(profileEntity)这将返回一个新持久的ProfileEntity，但是现在我需要将其映射到ProfileDto以便使其成为UserDto的一部分，然后再重新映射{{ 1}}到UserDto并保持不变。

注意：Dto是我打算用作对客户端的响应（带有JSON相关注释）的对象。它们生活在UserEntity和Service层中，而Entity是与JPA相关的对象，它们仅生活在Controller和Repository层中。