未分類
21 7 月 2020

service 层接收的参数 xxRequest 还是 xxDto ?

service 层接收的参数 xxRequest 还是 xxDto ?

資深大佬 : jerrry 4

比如 UserController 中有 List<UserDto> findUsers(UserSearchRequest xxRequest) { return userService.findUsers(…) } 方法,

那么 UserService 中的 List<UserDto> findUsers(…) 接收的参数应该怎么设计 ?

其中 UserSearchRequest 包括多个查询条件 ( keywords, username, age, time, city… ).

大佬有話說 (32)

  • 資深大佬 : damai0419

    直接用也可以，要么创建一个 xxxQuery 也可以。

  • 資深大佬 : zhangdashuan

    param

  • 資深大佬 : sheeta

    我用的是 xxRequest

  • 資深大佬 : lqs

    原则上 Service 层应该单独有一套业务对象，这样就可以把 UserService 里的接口设计成 List<UserBo> findUsers(UserSearchBo)，然后在 UserController 里对输入输出都做适配。

  • 資深大佬 : luxinfl

    我们小公司，没那么复杂，对外统称 dto 。有时候还用 domain 来作入参和返参。

  • 主 資深大佬 : jerrry

    @lqs 但是我的 controller 和 service 对应的查询参数一般都是一样的，所以这时候不知道怎么设计…

  • 主 資深大佬 : jerrry

    @luxinfl 对请求参数检验的话还是封装在 vo 里比较方便吧

  • 資深大佬 : wshcdr

    关注一下

  • 資深大佬 : hantsy

    UserDto 这种太通俗了。

    如果你想让你的代码做到 Self Documentation，可以学习 Spring 的命名，尽量取一个有意义的名字。

    如果应用了 CQRS，很多命名相对容易些。CreateUserCommand, UserCreatedEvent, 等。

    总之，尽量做到一个 Dto 仅仅封装所需要的数据，见过一些人为了省事，用一个巨无霸 Dto，完全没把 OOP 放在心上。

  • 資深大佬 : hantsy

    @lqs
    @jerrry

    VO，BO 是什么鬼东西，我写了十几年 Java，读了 N 多本书，没见过。

  • 資深大佬 : hantsy

    Value Object ？？？

  • 資深大佬 : hantsy

    DDD 中 Value Object 是相对于 Entity 来讲的。

  • 資深大佬 : Sharuru

    xxxForm，xxxModel，xxxParam 。
    针对主的场合，可以用 xxxCriteria 。

  • 資深大佬 : MarioLuo

    命名重要保持一致性就好，不过个人更倾向: XxxParams, XxxQuery 代表入参, XxxDTO,XxxInfo 代表出参，更符合自然语意些

  • 資深大佬 : oneisall8955

    跟项目，假如新项目看自己喜好

  • 資深大佬 : daimubai

    随主流
    接受用 xxxDTO （ DTO 大写可读性更高点吧）
    响应用 VO

  • 主 資深大佬 : jerrry

    @hantsy view object, api 返回的数据一般是和 entity 不一致的。

  • 主 資深大佬 : jerrry

    @Sharuru 谢谢，那如果它们所需的参数是一致的情况下，controller 层需要的参数对象和 service 需要的参数对象需要分成俩个吗？

  • 資深大佬 : yalin

    都是 DTO 层

  • 資深大佬 : memedahui

    最近刚好看了一个类似的文档,说的就是一共需要 3 个:
    接入层模型:view object 与前端对接的模型
    业务模型:领域模型,业务核心模型
    数据模型:

  • 資深大佬 : memedahui

    最近刚好看了一个类似的文档,说的就是一共需要 3 个:
    接入层模型: view object 与前端对接的模型
    业务模型: domain object 领域模型,业务核心模型
    数据模型: data object 数据模型,同数据库映射

  • 資深大佬 : liuxey

    @hantsy #10 bussiness object，远古时代 Java 里对象名字可太多了：BO VO DTO DO POJO

  • 資深大佬 : hantsy

    VO= Value Object，我觉得还不错，如果是 View Object，呵呵，这种创造太恐怖了。

  • 資深大佬 : hantsy

    @MarioLuo 接受自然语言这一条不错。
    实际各种层的传输数据，另外还有一个特质，Immutable 。

  • 資深大佬 : passerbytiny

    DTO，Data Transfer Object，数据转换对象。你要真是个 DTO，那是一个有状态 Java Bean （并且带大量方法，或者要用到工厂模式等各种模式），一般人用不起。

    如果要求上下层互不依赖，需要 DTO 来解藕。否则，谁是被依赖方，用谁定义的对象。

  • 資深大佬 : RedBeanIce

    DO （ Data Object ）：与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。
    BO （ Business Object ）：业务对象。由 Service 层输出的封装业务逻辑的对象。
    DTO （ Data Transfer Object ）：数据传输对象，Service 或 Manager 向外传输的对象。
    VO （ View Object ）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。
    Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用 Map 类来传输。

    以上摘抄自阿里巴巴 Java 开发手册（参考部分）

  • 資深大佬 : Rwing

    所有用 XXO,XO 都是懒人，这种废话写不写没什么意义，不能准确表述意图

  • 資深大佬 : ylsc633

    这问题不是 脉脉 里的么…..

  • 資深大佬 : tang123456

    目前我们公司是统一传参用 dto,反参用 vo

  • 資深大佬 : YzSama

    @RedBeanIce #26 直接沿用 阿里巴巴的规范就好了。

    这个最好看看 阿里 Java 开发规范 工程设计 那块，因为 service 层 存在对外服务。例如 RPC，所以统一 DTO 是反参。

    BO 是 Service 入参 。

    如果主的项目里，service 只是提供 controller 的话，因此 入参和校验 其实都是从 controller 来的。并不需要修改成 BO，直接沿用就好了。还少了一层转换

  • 主 資深大佬 : jerrry

    @YzSama 谢谢, 受教了。 不过如果用到 BO 的话, VO 如何转换到 BO 呢？是把转换逻辑封装到 VO 的一个方法里？还是单独写一个转换器类。

  • 主 資深大佬 : jerrry

    @RedBeanIce BO 和 DTO 的区别好像没看出来啊。。。