存在即是合理的，业务复杂，人员协同性要求高的场景下，这些规范性的东西不按着来虽然不会出错，程序照样跑，但是遵守规范会让程序更具扩展性和可读性，都是前辈血淋淋的宝贵经验，为什么不用？
随着现在后端编程标准化程度越来越高，各种编程模型层出不穷。作为Java开发人员，大部分人不免要接触VO，BO，PO，DO，DTO之类的，但很多同学对这些概念一直以来都是云里雾里，团队开发过程中也总是处于混乱的状态，抓起来就用，本来是规范性的东西，却反而导致更加混乱了。
今天我们把这些概念掰开揉碎来讲解一下，力求有一个清晰的理解，在开发中能有所助益。文中又理解不到位的，也欢迎大家斧正。
概念
VO（
View Object）：视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。DTO（
Data Transfer Object）：数据传输对象，这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，更符合泛指用于展示层与服务层之间的数据传输对象。BO（
Business Object）：业务对象，把业务逻辑封装为一个对象，这个对象可以包括一个或多个其它的对象。PO（
Persistent Object）：持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。DO（
Domain Object）：领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。
如果光看这些概念，可能大部分人都理解，但还是很绕，具体用的时候还是不能很好区分，我们来横向做个比较，理解会加深一些。
易混点一：VO和DTO
首先VO是最常用的，但对于这个概念，网上也是众说纷纭，value object 或 view object，一般说视图对象或者值对象，我更倾向理解为视图对象。说白了它就是展示用的，不管展示方式是网页，还是客户端，还是APP，只要是这个东西是让人看到的，我们就把它封装为VO。
VO比较容易混淆的是DTO，DTO是展示层与服务层之间传递数据的对象，可以这样说，对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，那么既然有了VO，为什么还需要DTO呢？
我们举例来说明一下：
某公司有一个后台服务，服务层有一个getUser的方法返回一个系统用户，包含sex(性别)、年龄。对于服务层来说，DTO只从语义上定义，可能是这样的：
{
"gender":"男",
"age":35
}