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

Question

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

我正在考虑使用DTO,原因如下:

1. 为了保护信息隐私,最大限度地减少要发送的不必要信息.
2. 减少json字符串的大小以提高性能.
3. 使用相同实体的不同UI可以具有不同的业务验证(即,强制/可选字段).我可以为同一个实体创建2个DTO并相应地注释验证.

我正在考虑使用DTO将多个实体合并在一起,根据角色隐藏/显示特定UI的某些信息,但是当我需要保留详细信息时,我必须将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 与这些映射库不兼容

祝你好运。