我是否应该考虑将DTO用于Spring Rest Controller层而不是实体？

我是否应该考虑将DTO用于Spring Rest Controller层而不是实体？

我总是使用DTO将我的视图与JPA实体分离。除了列出的3个原因外，我还可以添加以下内容。

• JPA通常在父子之间有双向引用，其中一个是真实的（存在于数据库中），另一个是合成的。序列化为JSON时，您只有父子关系，这是综合关系。
• 如果直接反序列化到实体，则必须完全了解分离的实体并进行合并。如果您曾经尝试合并大型循环实体图，那么您会知道这不是在公园散步。
• 对于JSON视图，性能也很重要。如果将实体用于JSON生成，则必须加载所有列。使用投影并直接在DTO中选择所需的列通常会更有效。
• 如果您有API，则可以将DTO放入一个单独的模块中，以供其他人作为依赖项重用，而您永远不想使用实体类来这样做。
• JB Nizet 提到了不变性，这也是一个好主意。使用

  @JSONCreator

  DTO可以拥有不可变的DTO，它具有一些优点-尽管大多数情况下DTO不在多线程上下文中使用，因此不需要。

在我的项目中，我总是使用Lombok生成访问方法，这意味着DTO通常仅包含数据字段（有时输入的DTO具有验证器或实用程序方法）。这使得它们超级易于创建/修改，并且易于与包含逻辑的类区分开。与编写业务逻辑相比，创建DTO无需花费时间，因此进行这种解耦的成本非常低，而且老实说，我相信这样做会使读取代码更容易。