在存在合理、业务复杂、要求人员协同性的情况下，请不要按这些规范。 没有错误。 程序跑得一样，但遵守规范会提高程序的可扩展性和可读性。 这是前辈血淋淋的宝贵经验。 为什么不用？
目前，随着后端编程标准化的深入，各种编程模式层出不穷。 作为Java开发者，大部分人都要接触到VO、BO、PO、DO、DTO等，但很多同学对这些概念从来都是云里雾里，团队开发中也总是处于混乱的状态，抓着用，本来就是规范的
今天的目标是把这些概念细分开来进行说明，有明确的理解，对开发有帮助。 文中不能理解的人，也欢迎大家斧正。
概念视图对象(VO )视图对象用于表示层，用于封装特定页面(或组件)上的所有数据。
dto (数据传输对象)数据传输对象这个概念源于J2EE的设计模式，它的初衷是通过为EJB的分布式APP应用提供粒度较粗的数据实体来减少分布式调用的次数
bo (business object (http://www.Sina.com/)将业务逻辑封装在一个对象中，可以包含一个或多个其他对象。
持久对象(po )业务对象与持久层(通常是关系数据库)的数据结构形成一对一映射关系，如果持久层是关系数据库，则为数据数据
域对象(do )持久化对象是从现实世界中抽象出来的有形和无形的实体。
光看这些概念，大部分人可能都理解，但还是太绕圈子了，具体使用时分不清。 横向比较的话，会加深理解。
容易混淆的一点： VO和DTO首先是VO最常用，关于这个概念在网络上也有很多说法。 value object和view object一般称为视图对象或value object，倾向于理解为视图对象。 说白了那是用来展示的。 无论展示方法是网页、客户端、APP，只要本身是给人看的，都打包为VO。
VO容易混淆的是DTO。 DTO是展示层和服务层之间传递数据的对象。 对于大多数APP应用程序场景，DTO和VO的属性值基本一致，而且他们通常是POJO，所以有VO为什么需要DTO呢？
领域对象
一家公司有后台服务，服务层有getUser方法，返回系统用户，包括sex (性别)、年龄。 对于服务层来说，DTO只在意义上定义，可能如下：
{'gender': '男'，' age':35}但此服务同时提供给多个客户端。 此外，不同表现层的要求也不同，比如管理者要求显示准确的年龄，APP应用端只需要显示一个年龄段即可保护客户隐私。
管理端VO :
{'gender': '男'，' age ' :35 } APP应用程序端VO :
{'gender': '男'，' age ' :30至40 }从本示例中可以看出，DTO必须存在。 根据职责单一原则，服务层只负责业务，与具体表现形式无关，DTO不应该与表现形式发生结合。 DTO定义的是原始数据，VO对于DTO数据来说，VO和DTO的使用方式已经相当清楚了。
(易混点2 ) BO和PO PO是永久对象。 仔细理解后，这是实体和数据库字段的对应。 一个PO的数据结构对应于库中表的结构，表中的一个记录是一个PO属性。 在许多情况下，PO仅作为PO用于添加或删除。
PO混淆的是BO，BO是业务对象，对应的是某个具体的业务块，可以包含多个属性、对象。 简而言之，BO可以被认为是PO的组合。
我们举例来说明一下：
PO-1为交易记录对象，PO-2为登记记录对象，PO-3为商品阅览记录对象，PO-4为购物车追加记录对象，PO-5为检索记录对象，BO为个人网站行为对象，BO对象： {PO-1； PO-2； PO-3； PO-4； PO-5}。 这样做的好处当然是，如果您在维护代码时查看BO，就可以知道此逻辑与表(PO )有关多少。
(易混圆点三) BO和DTO明确了BO和PO各自的用途后，发现BO和DTO可以重叠功能，同样排列组合PO。 那个BO的存在意义是什么呢？
从用途上来看，BO是业务对象，DTO是数据传输对象。 BO也可以排列结合数据，但其功能是向内的，例如上例的BO对象有{PO-1； PO-2； PO-3； PO-4； PO-5}还有其他字段属性，但在提供对外接口时，如果BO对象中的某些属性对象可能不可用或难以暴露在外，DTO只需根据BO提取所需的数据并对外提供
在这种关系中，数据内容通常没有变化。 内容的变化在BO内部业务计算时完成或说明v
O的时候完成。 DODO是领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。事实上，DO和PO在绝大部分情况下是一一对应的。阿里巴巴的开发手册中的定义DO等同于PO，即与数据库表结构一一对应，通过DAO层向上传输数据源对象。
上一张图，更加直观的展示这些名词使用的节点：
总结VO，BO，PO，DTO这样分层还是很有意义的。尤其在团队成员较多的情况下，结构更加一目了然，同时也能很大程度避免多端系统数据所需不一致时，有人修改属性影响其他页面。但也完全没有必要教条主义，把这些全部用上，需要根据所开发的业务复杂度来取舍，如果本身业务逻辑不负责，照搬全上反而让开发变的更复杂。
例如业务不复杂，根本没有多端展示的差异化，VO可以直接拿掉，直接使用DTO传输到前端数据即可。
同时在使用过程中，最重要的是要在团队中达成共识，概念一致，如果使用了这些，但各按各的理解来，甚至抓起来就直接用，反而会让代码变得更乱，还不如直接POJO、DTO打天下。
另附这些概念命名规范：
数据对象：xxxPO，xxx即为数据表名。(也可DO)
数据传输对象：xxxDTO，xxx为业务领域相关的名称。
展示对象：xxxVO，xxx一般为网页名称。
业务对象：xxxBO，xxx是业务名称。
推荐：
主流Java进阶技术（学习资料分享）
PS：因为公众号平台更改了推送规则，如果不想错过内容，记得读完点一下“在看”，加个“星标”，这样每次新文章推送才会第一时间出现在你的订阅列表里。点“在看”支持我们吧！