不了解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

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

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

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