阿里巴巴Java开发手册中的DO、DTO、BO、AO、VO、POJO定义

分层领域模型规约：

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

领域模型命名规约：

数据对象：xxxDO，xxx即为数据表名。
数据传输对象：xxxDTO，xxx为业务领域相关的名称。
展示对象：xxxVO，xxx一般为网页名称。
POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。

关系图：

Java开发过程中，基本实体类包都以entity或者model来称呼，可是不少项目中，却以Bo、Vo来命名，这几者分别代表什么意思呢？

Entity
最常用实体类，基本和数据表一一对应，一个实体一张表。

Bo(business object)
代表业务对象的意思，Bo就是把业务逻辑封装为一个对象（注意是逻辑，业务逻辑），这个对象可以包括一个或多个其它的对象。通过调用Dao方法，结合Po或Vo进行业务操作。

形象描述为一个对象的形为和动作，当然也有涉及到基它对象的一些形为和动作。比如处理一个人的业务逻辑，该人会睡觉，吃饭，工作，上班等等行为，还有可能和别人发关系的行为，处理这样的业务逻辑时，我们就可以针对BO去处理。

再比如投保人是一个Po，被保险人是一个Po，险种信息也是一个Po等等，他们组合起来就是一张保单的Bo。

业务对象，封装对象、复杂对象 ，里面可能包含多个类，业务基本操作。

Vo(value object)
代表值对象的意思，通常用于业务层之间的数据传递，由new创建，由GC回收。
主要体现在视图的对象，对于一个WEB页面将整个页面的属性封装成一个对象，然后用一个VO对象在控制层与视图层进行传输交换。

Po(persistant object)
代表持久层对象的意思，对应数据库中表的字段，数据库表中的记录在java对象中的显示状态，最形象的理解就是一个PO就是数据库中的一条记录。

好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。Vo和Po，都是属性加上属性的get和set方法；表面看没什么不同，但代表的含义是完全不同的。

Dto(data transfer object)
代表数据传输对象的意思
是一种设计模式之间传输数据的软件应用系统，数据传输目标往往是数据访问对象从数据库中检索数据
数据传输对象与数据交互对象或数据访问对象之间的差异是一个以不具任何行为除了存储和检索的数据（访问和存取器）
简而言之，就是接口之间传递的数据封装
表里面有十几个字段：id，name，gender（M/F)，age……
页面需要展示三个字段：name，gender(男/女)，age
DTO由此产生，一是能提高数据传输的速度(减少了传输字段)，二能隐藏后端表结构

Pojo(plian ordinary java object)
代表简单无规则java对象
纯的传统意义的java对象，最基本的Java Bean只有属性加上属性的get和set方法

可以额转化为PO、DTO、VO；比如POJO在传输过程中就是DTO

Dao(data access object)
代表数据访问对象的意思，是sun的一个标准j2ee设计模式的接口之一，负责持久层的操作 。这个基本都了解，Dao和上面几个O区别最大，基本没有互相转化的可能性和必要，主要用来封装对数据的访问，注意，是对数据的访问，不是对数据库的访问。

数据访问 (Data Access)，是应用程序链接到数据源 (Data Source) 访问数据的一种行为 (Behavior)，在大多数的应用程序中，经常会需要使用到数据，而这些数据可能来自很多不同类型的来源，像是数据库 (Database)，网络数据源，本机文件，或是异质性的来源 (例如在 Mainframe 上的 IBM DB2 数据库)，经由一层 (或多层) 中介代码或中间件 (Middleware) 进入数据源中，并且取出数据后送回应用程序中来处理。

JDBC数据访问操作按以下的流程进行： 1.准备资源； 2. 启动事务； 3. 在事务中执行具体数据访问操作； 4. 返回数据； 5. 提交/回滚事务； 6. 关闭资源，处理异常。

数据库的访问过程：1.加载数据库驱动； 2. 建立数据连接； 3. 创建Statement对象； 4.执行SQL语句； 5. 访问结果集；

表示一个数据访问对象。使用 DAO 访问数据库，包括插入、更新、删除、查询等操作，与 PO 一起使用。DAO 一般在持久层，完全封装数据库操作，对外暴露的方法使得上层应用不需要关注数据库相关的任何信息。

数据库增删改查方法。

DO 现在主要有两个版本：
①阿里巴巴的开发手册中的定义，DO（ Data Object）这个等同于上面的PO
②DDD（Domain-Driven Design）领域驱动设计中，DO（Domain Object）这个等同于上面的BO

Controller
代表控制层，主要是Action/Servlet等构成（Spring MVC则是通过@Controller标签使用）此层业务层与视图层打交道的中间层，负责传输VO对象和调用BO层的业务方法，负责视图层请求的数据处理后响应给视图层。

View
代表视图层的意思，主要是指由JSP、HTML等文件形成的显示层。

所以实际项目中，一般都是这样应用的：
控制层(controller-action)，业务层/服务层( bo-manager-service)，实体层(po-entity)，dao(dao)，视图对象(Vo-)，视图层(view-jsp/html)

个人解读

1.如果你写的web应用是一个CRUD的demo，那么一个DO就完全够用。

例如，写一个用户的增删改查，数据库中有一个user表，你建立一个UserDO，类中的字段和数据库中一致，当你需要对User操作时，就用UserDO进行数据存取。

那么问题来啦：

首先，例如user表中有一个叫做passWord的字段，保存了登录密码，这个字段肯定是不需要返回到页面上的，但是如果像上面的操作，直接把UserDO的对象返回给前台，必然会带来安全隐患；

其次，如果User中有些字段需要转换后才能正确显示(例如显示中文，保存的是英文，或者保存的是关联表中的id)，直接返回UserDO就只能在页面上用js写if…else…来区分值，很繁琐；

最后，如果你的页面上显示的数据是一个很大的结果集(调用了好几个接口的返回结果)，例如除了User信息还有Account信息，一个UserDO显然就不够用了；

VO的概念应运而生。

2.VO中我们写的字段都是前台所需要的，而不是对象的所有字段值；

VO中的字段格式都是符合前台页面显示所需的，需要中文就显示中文；

对于调用了好几个接口返回的结果集，可以封装一个VO，将所有结果整合后再返回给前端页面。

3.有些人肯定在想，我的DO和VO中字段大多数都是相同的，有必要再写这样一个类吗？

答案是有的！如果写的是比较小的web应用，字段不多，你觉得没有这个必要。但是如果写的是大一些的系统，字段越多，分层的优势就会越明显。(博主写的web不大，但是拿出一个类也是一百多个字段，深感头疼)

DO和VO之间的转换

1.两个POJO之间的属性值进行copy，最原始的方法就是手动复制，但是这样就会产生大量的set，get代码，业务逻辑才是重点好吗？！不能喧宾夺主；

2.还有种方法就是用Spring提供的BeanUtils，博主现在的项目中用的就是这个，感觉还可以，但是也有点小问题，例如copy日期需要先注册等；

3.使用Dozer。Dozer是一个对象转换工具，可以在两个JavaBean之间进行递归数据复制,并且这些JavaBean可以是不同的复杂的类型。有兴趣的同学可以去学习下。

例子：
想看更多例子，可见：https://www.zhihu.com/question/39651928

一、
1 、还是用户类 name phone 加了个password。那么你后端的PO属性也是这3个，一般数据库里这个表有几个字段你的PO就有多少属性，但是传输到前台或者展现时，我们不应该把password 密码这种东西也一起传过去，所以他们的DTO VO 就还是 name + phone po : name phone password dto : name phone vo : name phone

2、现在又加了一个 枚举的状态位 status 表示用户的一些特殊状态，前台不会直接显示，可能会根据这个状态产生后续的操作，po : name phone password status dto : name phone status vo : name phone

3、接着看下BO ，一个用户下面 肯定会关联很多其他的表比如用户设置 用户信息等，那么这个BO 下 不但有用户本身的一些属性，还包含了用户设置 和用户信息这两个类。

二、
事情：统计研发部门中的季度绩效（暂定以工程师填写的为准，当然实际上大部分不是）
过程：CTO发布统计绩效请求（附带要求：每个人对应的绩效等级）->各个组（也可以是子部门）负责人发布统计绩效请求（每个对应的绩效等级，并将绩效分为了3个方面）->每位开发工程师统计自己绩效（自身各个方面）；
可以从例子中看到：每个责任人要求都不同；
对于CTO，他需要知道的是该季度所用员工的绩效等级；这里可以认为VO：员工姓名、绩效等级；

开发工程师：需将本人这个季度的各个方面的表现都列出来：员工姓名、绩效等级、Ａ方面表现内容及等级、B方面表现内容及等级、C方面表现内容及等级、D方面表现内容及等级、E方面表现内容及等级、F方面表现内容及等级、E方面表现内容及等级；此处可认为是PO：员工姓名、绩效等级、A方面表现内容、A方面等级….E方面表现内容、E方面等级；

然后开发工程师将员工姓名、绩效等级、Ａ方面表现内容及等级、B方面表现内容及等级、C方面表现内容及等级内容传递给小组负责人；此处传递的对象就是DTO

小组负责人：从开发工程师中获取到数据后，经过评定，然后得出员工姓名、绩效等级、原因；此处的评定，可以理解为BO；

参考文档：https://blog.csdn.net/weixin_39884872/article/details/112870958

参考文档：https://segmentfault.com/a/1190000038198085

参考文档：https://www.cnblogs.com/EasonJim/p/7967999.html

参考文档：https://blog.csdn.net/uestcyms/article/details/80244407

参考文档：https://www.zhihu.com/question/39651928