VO、DTO、BO、PO、DO、POJO 数据模型的理解和实际使用
一、概念讲解
-
VO（View/Value Object）—— 视图对象
-
DTO（Data Transfer Object）—— 数据传输对象
-
BO（Business Object）—— 业务对象
-
PO（Persistent Object）—— 持久对象
-
DO（Data/Domain Object）—— 数据/领域对象
-
POJO（Plain Old/Ordinary Java Object）—— 以上模型的统称
-
POJO 是简单的 Java 对象，不包含业务逻辑、能够控制自己内部所有属性访问的 Java 对象。
二、使用场景
流程图解释：
- 用户发出请求（可能是填写表单），表单的数据在展示层被匹配为VO。
- 展示层把VO转换为服务层对应方法所要求的DTO，传送给服务层。
- 服务层首先根据DTO的数据构造（或重建）一个DO，调用DO的业务方法完成具体业务。
- 服务层把DO转换为持久层对应的PO（可以使用ORM工具，也可以不用），调用持久层的持久化方法，把PO传递给它，完成持久化操作。
对于一个逆向操作，如读取数据，也是用类似的方式转换和传递。
DTO（Data Transfer Object）数据传输对象
数据传输对象比较特殊，之所以将 DTO 绘制在 展示层 和 业务逻辑层 之间，是因为它有两种存在形式：
前端：它是以 Json 字串的形式存在
后端：它是以 Java 对象的形式存在
微服务之间 DTO 对象的模型鉴定形式：
服务（模块）与服务（模块）之间相对独立，我们可以将数据传输对象命名为 DTO
服务（模块）与服务（模块）之间不是独立，每一个都不是一个完整的业务模块，拆分可能仅仅是因为计算复杂度或者性能问题考虑拆分的问题，那么就不能将对象命名为 DTO，只能是 BO
VO（View/Value Object）—— 视图对象
VO 就是展示用的数据，不管展示方式是网页、客户端、APP，只要是这些数据用于展示给人看的就是 VO
VO VS DTO
区别一：
字段可能不一样，VO 会根据实际情况，对字段有所删减
区别二：
属性值可能不一样，VO 会根据 DTO 中对值进行展示业务对解释（比如：为不暴露数据库字段，修改属性名称、敏感字段不展示等等）
对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，因此没必要多此一举，但不要忘记这是实现层面的思维，对于设计层面来说，概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。
PO（Persistent Object）—— 持久对象
简单的说 PO 就是数据库中的记录，一个 PO 的数据结构对应着库中的表结构，表中的一条记录就是一个 PO 对象。对于 PO 来说，数量是相对固定的，不会超过数据库中表的数量。等同于 Entity，它两概念是一致的。
BO（Business Object）—— 业务对象
BO 就是 PO 的组合
简单解释：
比如：PO 是一个交易记录，BO 就是一个人全部的交易记录集合对象
复杂解释：
比如：PO1 是交易记录，PO2 是登录记录、PO3 是商品浏览记录、PO4 是添加购物记录，BO 就是个人网站行为对象
DO VS DTO
这两个的区别主要也是字段的删减。BO 对内，为了进行业务计算需要辅助数据或者一个业务有多个对外接口，BO 可能会含有很多接口对外所不需要的数据，因此 DTO 需要在 BO 的基础上选取自己所需的数据赋值。
DO（Data/Domain Object）—— 数据/领域对象
阿里开发手册
DO 等同于 PO
DDD 领域驱动设计
DO 等同于 BO
原文地址：http://www.cnblogs.com/xiaopiao/p/16807380.html
