这是一个创建于 2035 天前的主题，其中的信息可能已经有所发展或是发生改变。
比如 UserController 中有 List<UserDto> findUsers(UserSearchRequest xxRequest) { return userService.findUsers(...) } 方法,
那么 UserService 中的 List<UserDto> findUsers(...) 接收的参数应该怎么设计 ?
其中 UserSearchRequest 包括多个查询条件 ( keywords, username, age, time, city... ).
 | 1 damai0419 2020 年 7 月 14 日 直接用也可以，要么创建一个 xxxQuery 也可以。 |
 | 2 zhangdashuan 2020 年 7 月 14 日 param |
 | 3 sheeta 2020 年 7 月 14 日 我用的是 xxRequest |
 | 4 lqs 2020 年 7 月 14 日 原则上 Service 层应该单独有一套业务对象，这样就可以把 UserService 里的接口设计成 List<UserBo> findUsers(UserSearchBo)，然后在 UserController 里对输入输出都做适配。 |
 | 5 luxinfl 2020 年 7 月 14 日 我们小公司，没那么复杂，对外统称 dto 。有时候还用 domain 来作入参和返参。 |
 | 6 jerrry OP @lqs 但是我的 controller 和 service 对应的查询参数一般都是一样的，所以这时候不知道怎么设计... |
 | 8 wshcdr 2020 年 7 月 14 日 关注一下 |
 | 9 hantsy 2020 年 7 月 14 日 UserDto 这种太通俗了。 如果你想让你的代码做到 Self Documentation，可以学习 Spring 的命名，尽量取一个有意义的名字。 如果应用了 CQRS，很多命名相对容易些。CreateUserCommand, UserCreatedEvent, 等。 总之，尽量做到一个 Dto 仅仅封装所需要的数据，见过一些人为了省事，用一个巨无霸 Dto，完全没把 OOP 放在心上。 |
| 11 hantsy 2020 年 7 月 14 日 Value Object ？？？ |
| 12 hantsy 2020 年 7 月 14 日 DDD 中 Value Object 是相对于 Entity 来讲的。 |
 | 13 Sharuru 2020 年 7 月 14 日 xxxForm，xxxModel，xxxParam 。 针对楼主的场合，可以用 xxxCriteria 。 |
 | 14 MarioLuo 2020 年 7 月 15 日 via Android 命名重要保持一致性就好，不过个人更倾向: XxxParams, XxxQuery 代表入参, XxxDTO,XxxInfo 代表出参，更符合自然语意些 |
 | 15 itechify PRO 跟项目，假如新项目看自己喜好 |
 | 16 daimubai 2020 年 7 月 15 日 随主流 接受用 xxxDTO （ DTO 大写可读性更高点吧） 响应用 VO |
| 18 jerrry OP @Sharuru 谢谢，那如果它们所需的参数是一致的情况下，controller 层需要的参数对象和 service 需要的参数对象需要分成俩个吗？ |
 | 19 yalin 2020 年 7 月 15 日 都是 DTO 层 |
 | 20 memedahui 2020 年 7 月 15 日 最近刚好看了一个类似的文档,说的就是一共需要 3 个: 接入层模型:view object 与前端对接的模型 业务模型:领域模型,业务核心模型 数据模型: |
| 21 memedahui 2020 年 7 月 15 日 最近刚好看了一个类似的文档,说的就是一共需要 3 个: 接入层模型: view object 与前端对接的模型 业务模型: domain object 领域模型,业务核心模型 数据模型: data object 数据模型,同数据库映射 |
| 23 hantsy 2020 年 7 月 15 日 VO= Value Object，我觉得还不错，如果是 View Object，呵呵，这种创造太恐怖了。 |
 | 25 passerbytiny 2020 年 7 月 15 日 via Android DTO，Data Transfer Object，数据转换对象。你要真是个 DTO，那是一个有状态 Java Bean （并且带大量方法，或者要用到工厂模式等各种模式），一般人用不起。 如果要求上下层互不依赖，需要 DTO 来解藕。否则，谁是被依赖方，用谁定义的对象。 |
 | 26 RedBeanIce 2020 年 7 月 15 日  1 DO （ Data Object ）：与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。 BO （ Business Object ）：业务对象。由 Service 层输出的封装业务逻辑的对象。 DTO （ Data Transfer Object ）：数据传输对象，Service 或 Manager 向外传输的对象。 VO （ View Object ）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。 Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用 Map 类来传输。 以上摘抄自阿里巴巴 Java 开发手册（参考部分） |
 | 27 Rwing 2020 年 7 月 15 日 所有用 XXO,XO 都是懒人，这种废话写不写没什么意义，不能准确表述意图 |
 | 28 ylsc633 2020 年 7 月 15 日 这问题不是 脉脉 里的么..... |
 | 29 tang123456 2020 年 7 月 15 日 目前我们公司是统一传参用 dto,反参用 vo |
 | 30 YzSama 2020 年 7 月 15 日 @RedBeanIce #26 直接沿用 阿里巴巴的规范就好了。 这个最好看看 阿里 Java 开发规范 工程设计 那块，因为 service 层 存在对外服务。例如 RPC，所以统一 DTO 是反参。 BO 是 Service 入参 。 如果楼主的项目里，service 只是提供 controller 的话，因此 入参和校验 其实都是从 controller 来的。并不需要修改成 BO，直接沿用就好了。还少了一层转换 |
| 31 jerrry OP @YzSama 谢谢, 受教了。 不过如果用到 BO 的话, VO 如何转换到 BO 呢？是把转换逻辑封装到 VO 的一个方法里？还是单独写一个转换器类。 |
| 32 jerrry OP @RedBeanIce BO 和 DTO 的区别好像没看出来啊。。。 |
Select Language