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