在 spring 的项目中，是返回实体(entity) 还是 dto 好

[glacial]

各位 老铁 你们在做项目的时候是怎么返回的信息的

1. 返回 entity 的好处不用创建很多个 dto 可以节省时间 修改字段时只用修改一处即可

2. dto 不用暴露过多的字段 当然了可以通过 JsonIgnore 去控制 ，只是不能跟据不同的业务场景去控制字段显示, 缺点是 修改字段后都得去修改对应的 dto , 如果用的是 jpa 还得进行转换

只想的这些 欢迎补充

[comsweetcs]

DTO...数据传输对象。你说的一般是返回 VO 才对，dto 一般是用来区分前端像后端的传输吧。。。

[chendy]

业务简单直接的话，用 entity 可以
业务复杂之后，业务 /展示 和 实体耦合一起有时候会比较难受，拆 dto 会舒服一些

[IMCA1024]

request 实体->DTO 实体->entity 实体->VO 实体->response 实体

目前我们转了很多层。。。

[anakinsky]

我们公司微服务内部调用的返回都是 entity，给前端的都是按需封装成 VO 返回

[glacial]

@comsweetcs 得看自已业务 这个没有强制要求 我不要弄那么多层 所以 只用 dto 就可以了

[glacial]

@IMCA1024 那你们 维护起来不是很 麻烦

[ericgui]

@IMCA1024 慢不？

[idoggy]

你底层 orm 怎么弄的，一张表一个 class 的就弄成 dto 自己用的时候再封装成 entity

[liuch]

取决于你的项目复杂度。复杂的项目有很多层，不是查库出来就能返回的，这种不只有 dto，vo

[gaoli1992]

规范角度来说不应该返回 entity 实体，逼近 entity 中包含主建、创建时间、更新时间等信息，而这些信息不应该让前端知悉的。

[IMCA1024]

@ericgui 慢倒是不慢 多层转换

[IMCA1024]

@glacial 确实是。但没办法 规定
Java，微服务
我们 Feign 接口打 client 包 接参 request 返回 response
controller 传到 service 用 DTO
mapper 返回 vo

[comsweetcs]

@glacial 可能你的业务比较简单吧.像很多 Model 里的字段，其实前端确实没必要字段，比如一些时间字段等。使用 VO 或者你爱咋叫都行，重点是把这部分信息屏蔽，一来可以做安全控制，二来减少网络传输数据量，三来传得更快。我们用的就是 jpa，转换有一套成熟的代码封装方案吧，单体用 BeanUtils，数组列表用 DozerMapper 吧，自己再封装下，也没多麻烦。。。

[Cbdy]

https://www.v2ex.com/t/707841

[BuffDog]

哎，这种场景，C#的匿名对象是真的香，虽然 java 使用 map 能实现类似的操作，但还是太麻烦了

[Alex5467]

entity 数据包含前端不需要的数据,而且也不全啊!