POJO/DTO/DO/EO/VO/BO/PO/AO的含义和使用

客官°小女子只卖身不卖艺 2023-06-21 12:27 40阅读 0赞

# 关于POJO/DTO/DO/EO/VO/BO/PO/AO #

本文讨论 POJO/DTO/DO/EO/VO/BO/PO/AO 的定义，另外讨论了这些xO在controller、service、dao/mapper层里的使用规范。另外还稍微讨论了controller中是否要 “轻逻辑”，mapper接口的规范等等问题。

### 前言 ###

在我们的java项目中存在各种xO的概念，如POJO/DTO/DO/EO/VO，还有些后端开发可能不太常见的BO/PO/AO。这里结合阿里Java手册以及其他博客的知识总结一下。这些xO一般都具有简单的结构，如setter/getter/toString

*  POJO：Plain Old/Ordinary Java Object，是其他xO的统称。笔者也喜欢用bean来统称这些xO，但后来觉得不准确，因为bean一般指spring容器所管理的bean
 *  DTO：Data Transfer Object，用来作为Controller的出参和Service的出参。一般分为两类：Controller的入参叫xxxReqDTO，Service层的出参叫xxxRespDTO。也有很多系统并不分得这么细。
 *  DO：Data Object，用来和单表一一对应的实体类。也有资料显示DO是Domain Object（域对象），
    
     *  EO：Entity Object，实体对象。有些公司用来表示跟表一一对应的类，即相当于DO。
     *  PO：记得最初的阿里Java文档定义为Persistence Object，持久化对象，当时文档说是跟表一一对应的，不知道后来的文档为什么改成了DO（难道记错了?）
 *  VO：View Object，阿里Java文档中说用来跟前端页面一一对应的对象。偶尔会有用错的情形，比如用来作为Controller层的入参
 *  BO：Business Object，阿里Java文档说明由 Service 层输出的封装业务逻辑的对象。不理解
 *  AO：Application Object，应用对象，不知道什么用。

其实搞这么多xO，有时候真的会影响效率，尤其非大型公司需要快。

【阿里Java手册】
    POJO（Plain Ordinary Java Object）: 在本手册中，POJO 专指只有 setter/getter/toString 的简单类，包括 DO/DTO/BO/VO 等。
    DO（Data Object）：此对象与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。
    DTO（Data Transfer Object）：数据传输对象，Service 或 Manager 向外传输的对象。
    BO（Business Object）：业务对象，由 Service 层输出的封装业务逻辑的对象。
    AO（Application Object）：应用对象，在 Web 层与 Service 层之间抽象的复用对象模型，极为贴 近展示层，复用度不高。
    VO（View Object）：显示层对象，通常是 Web 向模板渲染引擎层传输的对象。
    Query：数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用 Map 类来传输。

总结：这么多O，都搞晕了，感觉常用的就只有DTO；和表一一对应的类要不要后缀都不是很重要，所以DO也不是说很常用（当然有更好，能快速识别）

### xO 的使用方法 ###

总结：controller入参用dto，出参也是dto（从service层返回的）；service层入参是dto，出参dto；dao层入参不建议用dto而是分拆，出参dto或do。dao层接口不要用map作为入参，有不用map和list作为出参。

*  http(s) 传参的方式
    
    常见如下
    
     *  键值对：Content-Type 是 `x-www-form-urlencoded` 。准确说是 “名值对”，因为是可以重复的，如 `?favor=music&favor=reading` 中的favor。
        
        特殊情况
        
         *  键值对传文件：Content-Type 是 `form-data`。跟 “键值对” 不同之处是可传文件
     *  传 JSON：Content-Type 是 `application/json`。注意和 “传JSON字串” 的表述区分开，后者是键值对的传参方式 `?jsonStr={}`
     *  路径参数：如 /user/9527，中的 9527 是路径参数
 *  Controller 入参
    
     *  参数少：采用 “键值对” 和 “路径参数”
     *  参数多、结构复杂：采用 “传JSON”。一般用 xxxReqDTO 接收
        
         *  注意：有时不区分这么细，将 xxxReqDTO 和 xxxRespDTO 合并用同一个，叫 xxxDTO
         *  “传JSON” 的同时也可以使用键值对方式。即JSON字串在请求方法体里，键值对参数追加在URL
 *  Controller 出参
    
     *  出参格式
        
         *  一般总是返回200的 http 状态码，并用固定的返回类封装起来，例如 ResponseDTO
         *  ResponseDTO 一般带有系统自定义的业务异常码、信息提示、时间、数据
     *  出参从 Service 层获得，一般不再二次处理，直接放在 ResponseDTO 的 “数据” 里。
     *  无出参用 ResponseDTO
 *  Service 层的入参
    
     *  接收Controller层传入的简单类型或者 xxxReqDTO（或 xxxDTO）
 *  Service 层的出参
    
     *  出参简单的，直接返回：如基本类型、包装类和String等
     *  出参复杂的，返回 xxxRespDTO（或 xxxDTO）
        
         *  注意：“返回 xxxRespDTO” 的表述也包括 List、PageInfo、Map<String, xxxRespDTO>等形式，**下文不再赘述**
     *  反例：
        
         *  【禁止】有时贪快，用DO 作为出参，是不好的实践，必须用 DTO
         *  【疑惑】是不是每个Service接口都要定义自己的 DTO，DTO 可以跨不同的 Service 接口复用吗? 这个真的很纠结，复制一份DTO比较独立但是代码却重复非常多，用继承又导致复杂化不直观
 *  Dao 层（Mapper）的入参
    
     *  简单和复杂的参数都分拆成基本类型、包装列和String等
        
         *  insert接口或update接口会有很多字段，全列出来会不会很麻烦? 这些接口的sql不太可能自己写，因为代码生成框架可以自动生成的，所以不麻烦
         *  【建议】建议别用 Service 层的 xxxReqDTO（或 xxxDTO）作为入参，因为通常并非DTO里的所有字段在sql里会用到
         *  【疑惑】其实这个还是有点纠结的，要不要定义一个 xxxQuery 作为 mapper的查询入参?
     *  反例：
        
         *  【禁止】禁止入参用 Map
         *  【建议】建议入参也别用 xxxDO，因为xxxDO势必有很多字段其实并不是sql里需要的
 *  Dao 层（Mapper）的出参
    
     *  简单的直接返回
     *  复杂的返回 xxxRespDTO（或xxxDTO）
        
         *  【建议】能不能用 xxxDO 作为mapper的出参? 这块不强制禁止，因为生成的sql就是返回这些的
     *  反例：禁止出参用 Map 或 List

### 其他思考 ###

*  controller层：对此层大家的共识是不要写重的逻辑。但是要轻逻辑到什么程度? 比如我比较喜欢的一种方式是接口参数校验在参数声明中进行，但controller的方法的大括号里仅仅有一行调用service层的代码。这种方式把参数的进一步校验也交给service了。其实这种做法虽然很简洁，但是可能很难复用service层的接口。所以，是不是可以保证controller层有轻的 “分发” 性质的代码? 例如一个接口既可以新增也可以修改，在controller层里判断operType，新增的话分发到新增的service接口里，修改的话分发到修改的service接口里。
 *  controller里的RequestMapping，一般可能叫 “路由”、“路由地址”，这可能是来源于前端router的概念；其实也可以叫endpoint（端点），这个称呼更加显得后端
 *  其实我不太建议用 “路径参数”，会容易混淆

@GetMapping("/user/list")
    public List<ListUserDTO> listUser(String name) { }
        
    和
    @GetMapping("/user/{name}")
    public List<ListUserDTO> listUser2(@PathVariable("name") String name) { }
      
    会符合 "精确匹配优先" 的原则，即访问/user/list匹配上面的，假设有个name是 "list" 值的，就没办法调用到下面的方法；如果是非 "list"，则匹配下面的方法。
    
    ------------------------------
    
    @GetMapping("/user/{name}")
    public List<ListUserDTO> listUser2(@PathVariable("name") String name){ }
    
    @GetMapping("/user/{id}")
    public QueryUserDTO queryUser(@PathVariable("id") Integer id){ }
    
    这两个方法能正常启动springboot，但是只有在运行时抛出异常，即无法确认要匹配哪个方法。因为前端的传参本质上是没有字串和整形的区分的，本质都是字串，只是在spring框架里如需要会进行转换。

* dao层的mapper接口真的不建议使用pojo作为入参，强烈建议把字段分拆成基本类型、包装类和String即可。原因是：1、这样清晰一点；2、一般入参的个数不会很多，比较多入参的insert接口都交给了代码生成，完全不需要自己写这样的sql。3、pojo作为入参，比如这个pojo是service层传如的xxxReqDTO，但是这个dto里并非所有字段都是sql里的条件，所以这会造成不好维护。
    * dao层的mapper更加不建议用map作为入参，看似灵活，实际过于灵活导致难以分析真正传入的参数
    * dao层的mapper接口出参也不建议用Map<String, Object> 或 List<Map<String, Object>>，看似灵活，实际也是过于灵活导致很难维护，比如从map中get值，key写错时很难发现。我们希望在编码的早期阶段尽快暴露出这些bug
    * service层的接口是可以调用其他同是service层的接口的。有时候为了共用接口，确实会有这样的需要。那被共用的接口是否要提取到类似CommonService里呢?  我建议是不需要不强制。