当前编程的工业化水平越来越高，各种各样的编程模型也越来越多，比如我们常用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合并成一个，当业务扩展的时候注意拆分就行
5.DO
DO 现在主要有两个版本：
①阿里巴巴的开发手册中的定义，DO（ Data Object）这个等同于上面的PO
②DDD（Domain-Driven Design）领域驱动设计中，DO（Domain Object）这个等同于上面的BO
最后，我们再谈一谈这些对象定义的实际应用
了解了概念后相信大家都会有疑问，实际工程中是否必须按照固定的概念来定义对象？
答案当然是否定的。各个系统复杂情况不同，概念只是一个辅助，没有必要做照搬概念的教条主义。设计出一个灵活易懂的系统才是我们的最终目标。
摘自：https://zhuanlan.zhihu.com/p/264675395
我平常使用的方式：
- VO：展示用的数据，不管展示方式是网页，还是客户端，还是APP，只要是这个东西是让人看到的，这就叫VO；
- Form：用来接收页面的入参，也就是在Controller里面定义的参数；
- BO：BO是一个业务对象，一类业务就会对应一个BO；
- PO：数据表记录对象，我一般把多表联查的记录返回为PO实例记录；
- Entiy：数据表记录对象，我一般把单表查询的记录返回为Entiy实例记录；
关于接收页面参数的模型后缀，PHP框架中：
- Laravel框架：Intput
- Yii框架：Form