81,120
社区成员
发帖
与我相关
我的任务
分享
...全文
请发表友善的回复…
发表回复
夜阑卧听风吹雨123 2020-12-02
- 打赏
- 举报
这种方式也是避免了写重复属性，但是对象还是那么多个对象
。不过这种方式倒是结构清晰
。不过这种方式倒是结构清晰
shanyan06 2020-12-02
- 打赏
- 举报
我们的做法是新建、修改都会建立单独的DTO，因为这些信息传递过来后往往都需要进行处理。另外针对数据库实体建立通用DTO，属性可以与数据库实体一致，亦可以额外关联一些明细通用DTO对象。传递给前端显示的VO继承通用DTO，在VO添加诸如创建人名称、机构名称等等额外信息。通过null
赋值的json转换，控制传递给前端的属性显示。
赋值的json转换，控制传递给前端的属性显示。
shanyan06 2020-12-02
- 打赏
- 举报
应该传的是vo 但是根据情况而定，尤其是前后分离，有特定的前端开发人员的时候。因为dto往往会添加很多额外的数据信息，打个比方，用户新增，往往前端传递的是账户名、密码、创建人标示等等很少的信息，但是dto作为一个中转数据，会添加例如更新人、用户状态等等其他的信息，如果前端传递的是dto，如此多的额外信息会给前端造成很多问题。如果是小项目的话，前后端都是一个人在进行，那就无所谓了，后端需要哪些，不需要哪些心里有数，传递dto就无所谓了。 一般的数据转换是，前端传递vo给接口，接口将vo转为dto传递给service，service将dto分解为do，调用领域服务进行调度，然后逆向转为vo或者其他的返回结果，传递给前台。[/quote]
有一个问题，前端传过来的数据和要返回的数据不一样，那就要定义两个VO，同时VO转DTO一次，DTO转DO一次，查询完数据库后DO转DTO一次，DTO转VO一次，DTO有可能还要定义多个，那么这样是不是有点麻烦，有什么解决办法吗？谢谢。[/quote]
简单的办法就是继承！不过我们的做法是建立一个通用的DTO，这个DTO可以与数据库实体一致或添加额外属性，然后创建、更新都有专门的DTO，VO继承通用DTO，VO中添加DTO之外的前端显示需要的额外属性，比如像用户昵称、机构名称等信息。
凉月满天易水寒 2020-09-25
- 打赏
- 举报
简单说点 前端传参 DTO ， 业务处理数据BO ，与数据库映射 DO，返回给前端VO。 按照最新版的阿里规范。
数据传输对象DTO,数据对象DO,展示对象VO，当然这是死的， 只要公司代码约定好了，就可。
走在四季 2020-09-22
- 打赏
- 举报
放在 BaseResult 中的 data 属性里
我们的 BaseResult 中就是 code ，data ， msg
cglandy 2020-09-22
- 打赏
- 举报
你的BaseResult还是要有表现对象吧？
廾匸随笔 2020-09-22
- 打赏
- 举报
如果你是在做一个新项目，且没有公司没有任何规定约束，那就按照上面大佬们说的去设计，如果是旧项目，那就问老员工或者直接看代码，这种问公司之外的人都是无用的。比如我们视图到控制层就是用dto，约定大于配置
走在四季 2020-06-03
- 打赏
- 举报
反正我们现在入参都是 dto ，返回都是封装的 BaseResult 类
夜阑卧听风吹雨123 2020-06-02
- 打赏
- 举报
应该传的是vo 但是根据情况而定，尤其是前后分离，有特定的前端开发人员的时候。因为dto往往会添加很多额外的数据信息，打个比方，用户新增，往往前端传递的是账户名、密码、创建人标示等等很少的信息，但是dto作为一个中转数据，会添加例如更新人、用户状态等等其他的信息，如果前端传递的是dto，如此多的额外信息会给前端造成很多问题。如果是小项目的话，前后端都是一个人在进行，那就无所谓了，后端需要哪些，不需要哪些心里有数，传递dto就无所谓了。 一般的数据转换是，前端传递vo给接口，接口将vo转为dto传递给service，service将dto分解为do，调用领域服务进行调度，然后逆向转为vo或者其他的返回结果，传递给前台。[/quote]
有一个问题，前端传过来的数据和要返回的数据不一样，那就要定义两个VO，同时VO转DTO一次，DTO转DO一次，查询完数据库后DO转DTO一次，DTO转VO一次，DTO有可能还要定义多个，那么这样是不是有点麻烦，有什么解决办法吗？谢谢。
芒果-橙 2020-06-02
- 打赏
- 举报
阿里巴巴编码规约中列举了下面几个领域模型规约：
DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。
AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
详细可参考原文：https://cloud.tencent.com/developer/article/1176367
CS_草祭先生 2020-06-02
- 打赏
- 举报
其实你说的VO和DTO是一个东西，是用作不同框架下针对控制器和页面交互的对象的命名方式而已，没有其他特殊含义，只是一个规范而已，你不这么命名也不影响代码开发。
_Dnf 2020-02-16
- 打赏
- 举报
为什么？ BO全称是什么呢？
javabro 2019-12-20
- 打赏
- 举报
不同场景的叫法。
Valerie00 2019-12-20
- 打赏
- 举报
controller 入参bo 出参vo 中间service层dto dao层entity
shanyan06 2019-12-20
- 打赏
- 举报
应该传的是vo 但是根据情况而定，尤其是前后分离，有特定的前端开发人员的时候。因为dto往往会添加很多额外的数据信息，打个比方，用户新增，往往前端传递的是账户名、密码、创建人标示等等很少的信息，但是dto作为一个中转数据，会添加例如更新人、用户状态等等其他的信息，如果前端传递的是dto，如此多的额外信息会给前端造成很多问题。如果是小项目的话，前后端都是一个人在进行，那就无所谓了，后端需要哪些，不需要哪些心里有数，传递dto就无所谓了。 一般的数据转换是，前端传递vo给接口，接口将vo转为dto传递给service，service将dto分解为do，调用领域服务进行调度，然后逆向转为vo或者其他的返回结果，传递给前台。
oh_Maxy 2019-09-30
- 打赏
- 举报
表现层对象和业务处理层对象，尽量不要耦合太深。
一般情况下，表现层传过来的VO，会做一些简单的校验，然后封装业务层需要的对象进行逻辑计算。
一般情况下，表现层传过来的VO，会做一些简单的校验，然后封装业务层需要的对象进行逻辑计算。
weixin_42664210 2019-09-29
- 打赏
- 举报
我想问问，我新手哈，service和dao交互用的不是DO吗？我用的是SSM框架。
苏颙 2018-05-07
- 打赏
- 举报
传vo， 因为controller本身就是和视图层（view）打交道。要和页面中的数据结构相同 更方便。dto是service与dao 数据持久层交互的。应该是这样
Chan_kwen 2018-05-05
- 打赏
- 举报
我也没有深入了解过，就我使用情况来说的话，VO和DTO在实际开发过程中其实可以是一样的。从定义上来说他们区别于使用的所在层，VO（view object）视图对象，DTO（Data Transfer Object），数据传输对象； 至于你这里的controller接收参数要看是接收service的参数还是页面传递过来的参数了，若是页面传递的参数叫VO，service传递的参数叫DTO。。
以上是我拙见，有什么错误的地方欢迎指出！
