java - 我是否应该考虑对 Spring Rest Controller 层使用 DTO 而不是实体？

Question

我作为初学者开始了一个 Spring Rest 项目。我的大多数实体都具有超过 15-20 个属性，并且并非 UI 层需要所有属性。

我考虑使用 DTO 的原因如下:

1. 出于信息隐私原因，尽量减少发送不必要的信息。
2. 为了提高性能而减小 json 字符串的大小。
3. 使用同一实体的不同 UI 可能具有不同的业务验证(即必填/可选字段)。我可以为同一实体创建 2 个 DTO，并相应地注释验证。

我正在考虑使用 DTO 将多个实体合并在一起，根据角色隐藏/显示某些 UI 的某些信息，但是当我需要保留详细信息时，我必须将 DTO 信息“拆分/复制”回不同的实体.

员工 - 能够查看下一级经理的绩效评估和评论。 经理 - 能够输入绩效考核的评论，并指示员工的加薪(这不会显示在员工的 UI 中)，但无法查看员工当前的工资。 HR - 能够查看所有 UI 的所有详细信息。

我想知道是否有更好的方法来处理此类问题，或者我的项目方向是否正确？

引用号:http://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application

Answer 1

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

• JPA 通常在父级和子级之间有双向引用，其中一种是真实的(存在于数据库中)，另一种是合成的。序列化为 JSON 时，您只有父子关系，这是合成的关系。
• 如果您直接反序列化为实体，则必须完全了解分离实体和合并。如果您曾经尝试过合并大型循环实体图，您就会知道这不是在公园散步。
• 对于 JSON View ，性能也很重要。如果您使用实体进行 JSON 生成，则必须加载所有列。使用投影并直接将所需的列选择到 DTO 中通常会更有效。
• 如果您有 API，则可以将 DTO 放入单独的模块中，该模块可以作为依赖项被其他人重用，并且您永远不想对实体类执行此操作。
• JB Nizet提到了不变性，这也是一个很好的观点。使用@JSONCreator您可以拥有不可变的DTO，这可以有一些优点 - 尽管大多数时候DTO不在多线程上下文中使用，因此不需要。

在我的项目中我总是使用 Lombok生成访问方法，这意味着DTO通常只包含数据字段(有时输入DTO具有 validator 或实用程序方法)。这使得它们非常容易创建/修改，并且很容易与包含逻辑的类区分开。与编写业务逻辑相比，创建 DTO 不需要时间，因此这种解耦的成本非常低，而且我真诚地相信它使阅读代码变得更容易。