服务层到底接收和返回什么对象。服务层的中转对象应该是什么 O?

[golangLover]

最近看阿里巴巴的编程规范都绕晕了。

controller 接受的 VO,一时有人说是 view object, 一时有人说是 value object. 文章抄来抄去，不知道哪个对。

传进 service 层的时候到底是进来的时候就转换成 dto，还是把 vo 作为入参。返回出去的时候到底是返回一个 dto，还是返回一个 VO?

service 层之中 例如远端返回一个复杂 json，然后我就选了几个参数作为一个暂时对象。但这对象我也不准备直接返回出去，而是打算再和其他数据聚合，再返回甚至不返回。那么这个暂时的对象，他是属于 VO 吗，还是属于 dto 什么的。
这个暂时对象是作为内部类写在同一个文件里呢，还是分类为什么对象呢。这个命名的问题也困扰了我很久。

先感谢大家。

[knightdf]

好几年没写 java 了，最近弄个 java 项目，各种 O 把我看绕了，看了解释还是有点蒙逼，难怪最卷语言啊

[potatowish]

vo 是返回到前端的视图对象，dto 是数据传输对象，dto 作为入参，vo 作为返参，我这样解释可能不是百分之百准确。

个人觉得没必要这么死板，这只是个规范而已，我就喜欢用 XXResult 和 XXParam

[securityCoding]

@potatowish 的确是，我的习惯是 req resp

[Yi23]

在我看来 DTO 只存在于不同服务间调用，如果是单服务的话没必要使用 DTO 对象。至于 VO，可以作为 service 层返回对象的封装，也可以认为是服务返回结果封装
说实话，我觉得叫 xxVO xxDTO 真的挺丑的，个人更加倾向使用 xxRequest xxResponse xxFacade 这种

[xuanbg]

我习惯返回的叫 VO，传入的叫 DTO 。其实不管什么 O 都一样，并没有什么本质的区别。分 VO 和 DTO，不过是方便前端组织接口参数和按需返回数据罢了。

[ChoateYao]

我觉得长参数就用 ParamsObject 挺好的，简单易懂。

[golangLover]

@potatowish 那种暂时的对象是作为内部类吗？作为 dto ？

[golangLover]

@Yi23 那服务内部的他应该叫什么名字，还有就是写在哪里？写服务里令一个服务有好几个 class. 写外面又不知道归类为什么对象

[golangLover]

@xuanbg 那中间聚合的对象呢？应该叫什么名字

[xuanbg]

@golangLover 哪来的中间聚合？我都是 xxxDto 一路传到 sql 方法里面，有些参数前端给不了也不影响，自己 set 进去就好。然后 sql 查询方法返回的类型就是 xxxVo 。

[zxCoder]

我直接返回字典 我用的 c#

[Yi23]

@golangLover 我更习惯 controller 接收 xxRequest 直接透传到 service 在 service 中转为 xxEntity 向下都使用 xxEntity ；如果是查询的 service 会封装一个 xxFacade 比如 userService 可能就会返回 userFacade ；

[liaojl]

map 一把梭🐶

[Joker123456789]

简单粗暴的理解一下就行了。

Controller 进出都是 VO，为的是 一旦前后端的交互数据有了改动，只需要改 controller 就行了，不需要去动 service 。
Service 进出都是 DTO，为的是 业务逻辑内部发生变化，跟外界无关，反正入参出参没改。
DAO 就要看情况了，如果是多表查询 一次返回多个表的字段作为一个数据集，为了数据结构的清晰 可以用 DTO 。其他情况基本进出都是 PO 。

但是 绝非雷打不动的，实际开发中可以酌情处理。

[golangLover]

@xuanbg 例如在 service 里用一些方法例如 reduce 啊 groupby 之类的。那这种操作可能我会拆分一些方法，因为他们可能比较长，方法总有返回值吧，那这些返回值是什么类型的 o 呢

[golangLover]

@Yi23 不太懂一个 facade 的意思。有类似的结构可能示范一下吗

[Yi23]

@golangLover 其实就是 valueObject 只是个人习惯称为 facade 对象(外观对象) hhh

[MidCoder]

业务开发里面就是各种 O 之间的转换，越复杂的架构，这种 O 越多。所有的性能损耗都是在 get/set 里面，90%的逻辑都是 get/set.