比如 UserController 中有 List<UserDto> findUsers(UserSearchRequest xxRequest) { return userService.findUsers(...) } 方法,
那么 UserService 中的 List<UserDto> findUsers(...) 接收的参数应该怎么设计 ?
其中 UserSearchRequest 包括多个查询条件 ( keywords, username, age, time, city... ).
 |
1
damai0419 Jul 14, 2020
直接用也可以，要么创建一个 xxxQuery 也可以。
|
 |
2
zhangdashuan Jul 14, 2020
param
|
 |
3
sheeta Jul 14, 2020
我用的是 xxRequest
|
 |
4
lqs Jul 14, 2020
原则上 Service 层应该单独有一套业务对象，这样就可以把 UserService 里的接口设计成 List<UserBo> findUsers(UserSearchBo)，然后在 UserController 里对输入输出都做适配。
|
 |
5
luxinfl Jul 14, 2020
我们小公司，没那么复杂，对外统称 dto 。有时候还用 domain 来作入参和返参。
|
 |
8
wshcdr Jul 14, 2020
关注一下
|
 |
9
hantsy Jul 14, 2020
UserDto 这种太通俗了。
如果你想让你的代码做到 Self Documentation，可以学习 Spring 的命名，尽量取一个有意义的名字。 如果应用了 CQRS，很多命名相对容易些。CreateUserCommand, UserCreatedEvent, 等。 总之，尽量做到一个 Dto 仅仅封装所需要的数据，见过一些人为了省事，用一个巨无霸 Dto，完全没把 OOP 放在心上。 |
|
11
hantsy Jul 14, 2020
Value Object ？？？
|
|
12
hantsy Jul 14, 2020
DDD 中 Value Object 是相对于 Entity 来讲的。
|
 |
13
Sharuru Jul 14, 2020
xxxForm，xxxModel，xxxParam 。
针对楼主的场合，可以用 xxxCriteria 。 |
 |
14
MarioLuo Jul 15, 2020 via Android
命名重要保持一致性就好，不过个人更倾向: XxxParams, XxxQuery 代表入参, XxxDTO,XxxInfo 代表出参，更符合自然语意些
|
 |
15
itechify PRO 跟项目，假如新项目看自己喜好
|
 |
16
daimubai Jul 15, 2020
随主流
接受用 xxxDTO （ DTO 大写可读性更高点吧） 响应用 VO |
 |
18
jerrry OP @Sharuru 谢谢，那如果它们所需的参数是一致的情况下，controller 层需要的参数对象和 service 需要的参数对象需要分成俩个吗？
|
 |
19
yalin Jul 15, 2020
都是 DTO 层
|
 |
20
memedahui Jul 15, 2020
最近刚好看了一个类似的文档,说的就是一共需要 3 个:
接入层模型:view object 与前端对接的模型 业务模型:领域模型,业务核心模型 数据模型: |
|
21
memedahui Jul 15, 2020
最近刚好看了一个类似的文档,说的就是一共需要 3 个:
接入层模型: view object 与前端对接的模型 业务模型: domain object 领域模型,业务核心模型 数据模型: data object 数据模型,同数据库映射 |
|
23
hantsy Jul 15, 2020
VO= Value Object，我觉得还不错，如果是 View Object，呵呵，这种创造太恐怖了。
|
 |
25
passerbytiny Jul 15, 2020 via Android
DTO，Data Transfer Object，数据转换对象。你要真是个 DTO，那是一个有状态 Java Bean （并且带大量方法，或者要用到工厂模式等各种模式），一般人用不起。
如果要求上下层互不依赖，需要 DTO 来解藕。否则，谁是被依赖方，用谁定义的对象。 |
 |
26
RedBeanIce Jul 15, 2020  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 Jul 15, 2020
所有用 XXO,XO 都是懒人，这种废话写不写没什么意义，不能准确表述意图
|
 |
28
ylsc633 Jul 15, 2020
这问题不是 脉脉 里的么.....
|
 |
29
tang123456 Jul 15, 2020
目前我们公司是统一传参用 dto,反参用 vo
|
 |
30
YzSama Jul 15, 2020
@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