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