我应该考虑将DTO用于Spring Rest Controller层而不是实体吗? [英] Should I consider using DTO for Spring Rest Controller layers instead of Entities?

问题描述

我已经作为一个初学者开始了一个Spring Rest项目.我的大多数实体都具有15-20个以上的属性，并且UI层上并非所有属性都是必需的.

I have started a Spring Rest project as a beginner. Most of my entities have more than 15-20 attributes and not all attributes are required on the UI layer.

出于以下原因，我正在考虑使用DTO:

I am considering using DTO for the following reasons:

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

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

I am considering using DTO to merge multiple entities together, hide/show certain information for certain UI based on the roles, but I have to "split/copy" the DTO information back to different entities when I need to persist the details.

工作人员-可以查看下一级经理的绩效评估和评论. 经理-可以输入绩效评估的注释，并指明员工的加薪幅度(这在员工的用户界面中未显示)，但无法查看员工的当前薪资. HR-能够查看所有UI的所有详细信息.

Staff - Able to view the performance appraisal and comments by the next level manager. Manager - Able to enter comments for the performance appraisal, and indicate the pay increment for the staff (This is not shown in the staff's UI), but not able to view the staff's current pay. HR - Able to view all the details for all UI.

我想了解是否有更好的方法来解决此类问题，或者我正在为我的项目指明正确的方向?

I would like to find out if there is a better way to handle such concerns or am I heading the right direction for my project?

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

推荐答案

我始终使用DTO将视图与JPA实体分离. 除了您列出的3个原因之外，我还可以添加以下内容.

I always use DTOs to decouple my views from my JPA entities. In addition to the 3 reasons you list I can add the following.

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

• JPA often have two-way references between parent and child, one of them is real (exist in the DB) the other is synthetic. When serializing to JSON you only have the parent-child relation, which is the synthetic one.
• If you deserialize directly to an Entity, you have to have a complete understanding of detached entities, and merging. If you have ever tried to merge large cyclic entity graphs, you will know this is not a walk in the park.
• For JSON views performance can also be important. If you use the entity for JSON generation, you have to load all columns. It is often more efficient to use a projection, and select the columns you need directly into a DTO.
• If you have an API, you can put the DTO into a separate module that can be reused as a dependency by others, and you never want to do that with entity classes.
• Immutability was mentioned by JB Nizet, which is also a good point. using @JSONCreator you can have immutable DTO, which can have some advantages - although most times DTOs are not used in a multi threaded context, and therefore not needed.

在我的项目中，我总是使用 Lombok 来生成访问方法，这意味着DTO通常仅包含数据字段(有时输入的DTO具有验证器或实用程序方法).这使得它们超级易于创建/修改，并且易于与包含逻辑的类区分开.与编写业务逻辑相比，创建DTO无需花费时间，因此进行这种解耦的成本非常低，而且老实说，我相信这样做会使读取代码更容易.

In My projects I always use Lombok to generate access method, which means that DTOs usually only contain the data field (sometimes input DTO has validator or utility method). This makes them super easy to create/modify, and easy to distinguish from classes that contain logic. Creating the DTOs takes no time compared to writing the business logic, so there is very little cost of having this decoupling, and I honestly believe it makes it easier to read the code.

这篇关于我应该考虑将DTO用于Spring Rest Controller层而不是实体吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！