我应该考虑将DTO用于Spring Rest Controller层而不是实体吗？
我作为初学者开始了Spring Rest项目。 我的大多数实体都有超过15-20个属性，并且UI层上不需要所有属性。
我正在考虑使用DTO，原因如下：
- 为了保护信息隐私，最大限度地减少要发送的不必要信息。
- 减少json字符串的大小以提高性能。
- 使用相同实体的不同UI可以具有不同的业务validation（即，强制/可选字段）。 我可以为同一个实体创建2个DTO并相应地注释validation。
我正在考虑使用DTO将多个实体合并在一起，根据角色隐藏/显示特定UI的某些信息，但是当我需要保留详细信息时，我必须将DTO信息“拆分/复制”回不同的实体。
员工 – 能够查看下一级经理的绩效评估和评论。 经理 – 能够为绩效评估输入评论，并指出员工的薪资增量（这不会显示在员工的用户界面中），但无法查看员工当前的薪酬。 HR – 能够查看所有UI的所有详细信息。
我想知道是否有更好的方法来处理这些问题，或者我是否正朝着项目的正确方向前进？
参考： http ： //www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application
我总是使用DTO将我的观点与我的JPA实体分离。 除了列出的3个原因，我还可以添加以下内容。
- JPA通常在父和子之间有双向引用，其中一个是真实的（存在于DB中），另一个是合成的。 序列化为JSON时，您只有父子关系，这是合成关系。
- 如果直接反序列化为实体，则必须完全了解分离的实体和合并。 如果您曾尝试合并大型循环实体图，您将知道这不是在公园散步。
- 对于JSON视图，性能也很重要。 如果您使用实体生成JSON，则必须加载所有列。 使用投影通常更有效，并直接在DTO中选择所需的列。
- 如果您有API，则可以将DTO放入一个单独的模块中，该模块可以作为其他人的依赖项重用，而您永远不希望使用实体类。
- JB Nizet提到了不变性，这也是一个好点。 使用
@JSONCreator你可以拥有不可变的DTO，它可以有一些优点 – 虽然大多数时候DTO不用于multithreading上下文，因此不需要。
在我的项目中，我总是使用Lombok生成访问方法，这意味着DTO通常只包含数据字段（有时输入DTO有validation器或实用程序方法）。 这使得它们非常容易创建/修改，并且易于与包含逻辑的类区分开来。 与编写业务逻辑相比，创建DTO没有时间，因此实现这种解耦的成本非常低，而且老实说我相信这样可以更容易地阅读代码。