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

Question

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

我正在考虑使用DTO，原因如下：

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

我正在考虑使用DTO将多个实体合并在一起，根据角色隐藏/显示特定UI的某些信息，但我必须＆＃34;分割/复制＆＃34;当我需要保留详细信息时，DTO信息会返回给不同的实体。

员工 - 能够查看下一级经理的绩效评估和评论。 经理 - 能够输入绩效评估的评论，并指出员工的薪资增量（这不会显示在员工的用户界面中），但无法查看员工的当前薪酬。 HR - 能够查看所有UI的所有详细信息。

我想知道是否有更好的方法来处理这些问题，或者我是否正在为我的项目寻找合适的方向？

参考：http://www.baeldung.com/entity-to-and-from-dto-for-a-java-spring-application

Answer 1

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

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

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

Answer 2

最好使用DTO拥有干净的体系结构，并且使用DTO，当您修改Table时，FrontEnd不会有任何更改。

但是最好小心使用它。

1. DTO不是免费的，您应该为可维护性，代码行（更多的代码，更多的错误）付费，您应该对ROI有所了解。
2. 如果您有5个以上的开发人员，并且您从事的是大型项目，那么可以。
3. 对于新的From Scratch项目，不要以DTO开头，因为它太重了，首先要让您的应用程序运行，专注于业务层，而不是控制器或表示。
4. 您无需为每个实体创建DTO，只需创建所需的事实，实际上，您始终可以通过使用JsonView或创建新的API来解决问题，这对于维护更为有利。
5. 您可以使用JsonView，JsonIgnore而不是DTO来定制响应，它非常适合中小型项目。
6. 使用映射器库，我建议将modelMapper用于简单项目，将Orika用于复杂项目，注意，Lombok与这些映射器库不兼容

祝你好运。