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

ilovetolearn

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

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

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

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

员工-可以查看下一级经理的绩效评估和评论。经理-可以输入绩效评估的注释,并指示员工的加薪幅度(这在员工的UI中未显示),但无法查看员工的当前薪资。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无需花费时间,因此进行这种解耦的成本非常低,并且老实说,我相信这样做会使读取代码更容易。

本文收集自互联网,转载请注明来源。

如有侵权,请联系 [email protected] 删除。

编辑于
0

我来说两句

0 条评论
登录 后参与评论

相关文章

Spring Data REST HATEOS:不是延迟加载

Spring数据REST findBy嵌套实体

Spring Rest API验证应该在DTO中还是在实体中?

Spring Boot REST Controller Integration Test返回406而不是500

是否应该将实体转换为Repository对象中的DTO并将其返回到服务层?

Spring Rest Controller返回特定字段

Spring Boot Rest Controller非常慢的响应

为什么使用Apache Camel rest DSL而不是spring boot rest controller?

在Spring Boot Rest Controller中使用与其他实体引用一起映射到Hibernate实体的JSON时使用Jackson InvalidTypeIdException

Spring Rest Controller继承

我是否应该将.done()和.fail()用于新的jQuery AJAX代码,而不是成功和错误

Spring Rest端点和服务层分离

Java客户端,用于将复杂的实体发布到Spring Data REST / HATEOAS服务

为什么在JHipster中在服务层而不在REST层中生成DTO?

Spring Rest Controller跟踪实体视图计数

Spring Log for Rest Controller

用于Spring Boot Rest Controller的Junit

我应该在同一个REST实体上提供不同的视图吗?

我应该将EF中的实体视为领域模型还是DTO?

通过XML将属性注入Spring Rest Controller

使用Pojo而不是Rest Controller时,Spring Service注入为Null

使用Spring Integration的REST API层编排

通过Spring正确的JSON REST Controller

Spring Rest`@ Controller`的行为更加糟糕

在 Spring Data REST 中将父实体和子实体公开为 REST 存储库

用于更新地图的 REST API 是否应该允许将地图设置为空?

我有自定义注释@DTO 将主体从 dto 转换为实体,但是 swagger 将实体用于创建参数而不是 DTO

将实体转换为 dto 的最佳方法是什么?对于 Spring REST API 应用程序

在我的项目架构中从实体映射到 DTO 的层