JavaWeb - 我们的开发规范（VO、DTO、BO、PO、DO、POJO）

网传一张图

PO（Persistant Object）持久对象

PO比较好理解

简单说PO就是数据库中的记录，一个PO的数据结构对应着库中表的结构，表中的一条记录就是一个PO对象

通常PO里面除了get，set之外没有别的方法

对于PO来说，数量是相对固定的，一定不会超过数据库表的数量

等同于Entity，这俩概念是一致的

BO（Business Object）业务对象

BO就是PO的组合

简单的例子比如说PO是一条交易记录，BO是一个人全部的交易记录集合对象

复杂点儿的例子PO1是交易记录，PO2是登录记录，PO3是商品浏览记录，PO4是添加购物车记录，PO5是搜索记录，BO是个人网站行为对象

BO是一个业务对象，一类业务就会对应一个BO，数量上没有限制，而且BO会有很多业务操作，也就是说除了get，set方法以外，BO会有很多针对自身数据进行计算的方法

为什么BO也画成横跨两层呢？原因是现在很多持久层框架自身就提供了数据组合的功能，因此BO有可能是在业务层由业务来拼装PO而成，也有可能是在数据库访问层由框架直接生成

很多情况下为了追求查询的效率，框架跳过PO直接生成BO的情况非常普遍，PO只是用来增删改使用

BO和DTO的区别

这两个的区别主要是就是字段的删减

BO对内，为了进行业务计算需要辅助数据，或者是一个业务有多个对外的接口，BO可能会含有很多接口对外所不需要的数据，因此DTO需要在BO的基础上，只要自己需要的数据，然后对外提供

在这个关系上，通常不会有数据内容的变化，内容变化要么在BO内部业务计算的时候完成，要么在解释VO的时候完成

DO是什么

一个是阿里巴巴的开发手册中的定义：DO（ Data Object）这个等同于上面的PO

另一个是在DDD（Domain-Driven Design）领域驱动设计中，DO（Domain Object）这个等同于上面的BO

我们的规范

开发规范

Domain 分层领域模型规约

（1）、Basic：公共对象，所有 NO 级的公共类放到 basic 包下，如：BaseXxx

（2）、PO（Persistent Object）：持久化对象，xxxPO，xxx 即为数据表相关名

（3）、BO（Business Object）：业务对象，作用一：联表查询，多个 PO 组成 BO 的情况；作用二：Service层中间状态处理一律用 BO 来替代 Map（除非是动态的Map），如果 PO 可以复用拿来即用（奥母卡剃刀）

（4）、DTO（Data Transfer Object）：数据传输对象，Service 或 Client 出入对象；如果 Service 层返回分页实体类，分页实体类就是DTO，比如：Page<PO>, 那么这个整体就是一个DTO，包括类似 List<PO>，那么整个就可以看成是 DTO（BO 同理可得）

（5）、VO（View Object）：显示层对象，Controller 出入对象；Controller 层统一封装返回 ResultVO

Ps1：Common 模块：领域模型实体类（domain.basic/vo/dto/bo/po），如：ResultVO 位于 domain.vo

Ps2：工具类封装实体类时，禁止带XxxNO，取名尽量靠近工具类业务本身含义，如：JsonModel 形参

Ps3：只允许 Basic/VO 可以设定默认值

Ps4：Service private 方法出/入参封装不作限制，但禁止使用静态 Map

其他规约

禁止无共识的缩写
注释：类、接口、方法、代码、字段
数据库表名格式：t_项目/模块名_po名
Client 模块命名格式：xxxClient（只含接口），每次迭代更新版本号
公共异常类封装，尽可能减少代码中出现没必要的 try...catch...（统一处理）
日志打印：INFO：无论如何都要打印（微服务出入必须打印），DEBUG：排查问题打印
私有方法、工具类等非 MVC 分层方法：形参个数不做限制，除非复用率很高需要封装
Common 项目模块：领域模型实体类（domain）、工具类（util）、常量类等，每次迭代更新版本号
访问修饰符：Controller 不允许存在 private，统一挪到 Service 处理；类中修饰符顺序位置：public -> protected -> default -> private
代码必须符合 Alibaba & Sonarqube 规范
MapStruct 查看详情