不知道大家在自己的系统中发现很多类都是以BO、VO、DTO、DO结尾的类，这些存储数据的简单类，有什么作用呢？
我理解有二个作用:
-
一般稍大的系统都是分层设计的，最底层是数据存储层，数据库，最上层是对外提供接口调用的应用/视图层，那每一层都有关联的数据对象，所以需要做相应的区分。
-
让类语义更明确，很容易知道类的含义。
定义
先来看看阿里巴巴开发规约的定义：
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层输出的封装业务逻辑的对象。
- Query：数据查询对象，各层接收上层的查询请求。额外规定：【强制】超过2个参数的查询封装，禁止使用Map类来传输。
- VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
—《阿里巴巴Java开发规约》
详细各个词的定义:
DAO： Data Acess Object，数据访问对象，这个我们不陌生，跟数据库打交道的系统都会有这样的DAO类，主要的作用:
- 封装对数据库的访问，常规的增删改查（CRUD操作）都通过DAO来实现。
PO/DO: Persistent Object / Data Object，持久对象 / 数据对象。
-
跟数据库表是一一对应的，一个PO/DO 数据是表的一条记录。
-
以前用Hibernate 的时候PO用的很多，现在普遍喜欢用 DO，这个看各个公司自己的规范。
-
PO / DO 只是数据的对象，不包含任何的操作。举个例子，学生表是StudentDO，对学生表的增删改查等操作就是StudentDAO。
DTO：Data Transfer Object，数据传输对象
- 在分布式系统中，系统之间可以通过DTO进行数据传输；
- DTO也可以在应用内部，核心层和应用层之间传递数据，DTO只是简单的数据传输，没有业务逻辑的处理；
- 有的场景，比如数据库表有10个字段，id(唯一id)、version(版本号)，gmt_create(记录创建时间) 这些字段不需要对外提供，所以DTO 可以只取有含义的业务字段，DO是和数据库记录的一一映射，但是DTO只需要按照业务需要定义需要的字段。
BO : Business Object, 业务对象
BO主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。
-
在领域模型中，BO是个非常重要的概念, BO是最小的业务单元。
-
BO 包含数据对象（PO/DO）以及对数据的操作。
VO: View Object, 视图模型，展示层对象
对应页面显示（web页面/移动端H5/Native视图）的数据对象。
- 举个例子，DTO 中时间Date格式，或者是 yyyyMMddHHmmss的字符串，但是VO需要的是前端展示的格式，需要转成”yyyy年MM月dd月"；
实践
讲了这么多概念，我们再看下实操，先说命名：
领域模型命名规约 1） 数据对象：xxxDO，xxx即为数据表名。 2） 数据传输对象：xxxDTO，xxx为业务领域相关的名称。 3） 展示对象：xxxVO，xxx一般为网页名称。 4） POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO
再以学生档案管理系统为例，我们现在需要做个学生档案管理的后台系统，按照上面的定义，我们能定义出以下一些对象:
如下图所示：
DB层这里应该叫存储层，这里只列了DB，还有类似HBase、Redis，泛指储存数据。
以Student表为例，DB层负责存储。
-
DAO层提供了查询、删除、写入的接口；
-
DO 就是DAO操作的对象，这里是StudentDO，有时候也会省略DO，直接写Student；
-
service层或core层是做业务逻辑处理的，比如查询接口，根据学生学号调用DAO层获取Student信息，之后做一次数据裁剪，只取业务字段，例如版本号、自增id、数据库记录创建时间等非业务字段不取，获取一个StudentDTO，然后查询学生档案相关的ProfileDTO，组装成ProfileBO，作为档案领域模型；
-
业务层从service 层拿到这个BO，对BO做一个视图转化，转成VO视图对象，提供给前端负责展示。
大学刚毕业实习那会写了一个业务层直接调用DAO层的代码，觉得中间要经过服务层、核心层过于繁琐，字段都差不多，但是后面被Team Leader 指导了。
他告诉我说，VO 和 DO都可能会随着需求变化，软件设计的原则是降低耦合，一杆到底这种设计就是强耦合，DO变化的时候因为BO的存在，不需要修改VO，VO修改也同样不需要修改DO数据模型。 VO（视图） 和 DO（数据模型）都可能会随着需求变化，软件设计的原则是降低耦合，一杆到底这种设计就是强耦合（把视图和数据直接绑定），DO变化的时候因为DTO（数据传输对象）、BO（领域模型）的存在，不需要修改VO，VO修改也同样不需要修改DO数据模型。
