不了解VO,BO,PO,DO,DTO?这一篇就够了

当前编程的工业化水平越来越高,各种各样的编程模型也越来越多,比如我们常用MVC、MMVC等。与这些编程模型一块需要了解的还有各种各样的对象定义,比如VO,BO,PO,DO,DTO等等,如果不了解这些名称的含义跟概念,就会对新业务难以理解,让人越看越不明白。

因此,若要先了解模型,那就需要先弄明白对象定义的概念。这也是本篇文章的主要目的。

我们先从数据的流转角度来看看各个对象的定义

我们先从最开始的VO开始介绍

  1. VO

VO(Value Object)值对象

VO就是展示用的数据,不管展示方式是网页,还是客户端,还是APP,只要是这个东西是让人看到的,这就叫VO VO主要的存在形式就是js里面的对象(也可以简单理解成json)

注:在展示业务不复杂的系统,可直接使用DTO

2.DTO

DTO(Data Transfer Object)数据传输对象

DTO有两种存在形式:
①在后端,他的存在形式是请求的入参,也就是在controller里面定义的参数
②在前端,他的存在形式通常是js里面的对象(也可以简单理解成json),也就是通过ajax请求的那个数据体

注:这个传输通常指的前后端之间的传输,DTO本身的一个隐含的意义是要能够完整的表达一个业务模块
的输出。如果服务和服务之间相对独立,那就可以叫DTO;如果服务和服务之间不独立,每个都不是一个完整的
业务模块,拆开可能仅仅是因为计算复杂度或者性能的问题,那这就不能够叫做DTO,只能是BO。

3.PO

PO(Persistant Object)持久对象

简单说PO就是数据库中的记录,一个PO的数据结构对应着库中表的结构,表中的一条记录就是一个PO对象通常PO里面除了get,set之外没有别的方法。对于PO来说,数量是相对固定的,一定不会超过数据库表的数量,等同于常说的Entity

4.BO

BO(Business Object)业务对象

BO是一个业务对象,一类业务就会对应一个BO,数量上没有限制。而且BO会有很多业务操作,也就是说除了PO对象的get,set方法以外,BO会有很多针对自身数据进行计算的方法。
现在很多持久层框架自身就提供了数据组合的功能,因此BO有可能是在业务层由业务来拼装PO而成,也有可能是在数据库访问层由框架直接生成。
很多情况下为了追求查询的效率,框架跳过PO直接生成BO的情况非常普遍,PO只是用来增删改使用。

注:一个简单的例子就是PO1是交易记录,PO2是登录记录,PO3是商品浏览记录,PO4是添加购物车记录,
PO5是搜索记录,BO是个人网站行为对象
一些工具类的系统和一些业务不是很复杂的系统DTO是可以和BO合并成一个,当业务扩展的时候注意拆分就行
  1. DO
DO 现在主要有两个版本:
①阿里巴巴的开发手册中的定义,DO( Data Object)这个等同于上面的PO
②DDD(Domain-Driven Design)领域驱动设计中,DO(Domain Object)这个等同于上面的BO

最后,我们再谈一谈这些对象定义的实际应用

了解了概念后相信大家都会有疑问,实际工程中是否必须按照固定的概念来定义对象?

答案当然是否定的。各个系统复杂情况不同,概念只是一个辅助,没有必要做照搬概念的教条主义。设计出一个灵活易懂的系统才是我们的最终目标。
有什么问题欢迎与我交流

你可能感兴趣的