上才艺，哦不，上图...
Entity
最常用实体类，基本和数据表一一对应，一个实体一张表。
DAO(Data Access Object)：数据访问对象。
是sun的一个标准j2ee设计模式的接口之一，负责持久层的操作 。这个基本都了解，Dao和上面几个O区别最大，基本没有互相转化的可能性和必要，主要用来封装对数据的访问，注意，是对数据的访问，不是对数据库的访问。
PO(Persistant Object)：持久层对象。
对应数据库中表的字段，数据库表中的记录在java对象中的显示状态，最形象的理解就是一个PO就是数据库中的一条记录。
BO(business object)： 业务对象。
封装业务逻辑为一个对象(可以包括多个PO，通常需要将BO转化成PO，才能进行数据的持久化，反之，从DB中得到的PO，需要转化成BO才能在业务层使用)。
形象描述为一个对象的形为和动作，当然也有涉及到其他对象的一些形为和动作。比如处理一个人的业务逻辑，该人会睡觉，吃饭，工作，上班等等行为，还有可能和别人发关系的行为，处理这样的业务逻辑时，我们就可以针对BO去处理。
再比如投保人是一个PO，被保险人是一个PO，险种信息也是一个PO等等，他们组合起来就是一张保单的BO。
DTO(Data Transfer Object)：数据传输对象。
前端调用时传输；也可理解成“上层”调用时传输。
比如我们一张表有100个字段，那么对应的PO就有100个属性。但是我们界面上只要显示10个字段，客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.
VO(Value Object): 值对象。
VO就是展示用的数据，不管展示方式是网页，还是客户端，还是APP，只要是这个东西是让人看到的，这就叫VO。VO主要的存在形式就是js里面的对象(也可以简单理解成Json)
Pojo(Plain Ordinary Java Object)：纯的传统意义的Java对象。
最基本的Java Bean只有属性加上属性的get和set方法。Pojo可以额转化为PO、DTO、VO。比如POJO在传输过程中就是DTO。
DO是什么？
上面这些概念基本上已经涵盖了全部的流程，DO只是跟其中一个概念相同。但是跟哪个概念相同呢？现在主要有两个版本。
一个是阿里巴巴的开发手册中的定义， DO( Data Object) 这个等同于上面的PO。
另一个是在DDD(Domain-Driven Design)领域驱动设计中， DO(Domain Object) 这个等同于上面的BO。
这几个概念很完整，我们在用的时候是必须按这个来做吗？
当然不是的，系统和系统的复杂度不同，协作水平不同，完全没有必要教条主义，这些概念全上。上哪些概念，省哪些，我给一些实际建议
1. PO这个没法省，不管叫PO还是Entity，怎么着都得有。
2. 一些工具类的系统和一些业务不是很复杂的系统DTO是可以和BO合并成一个，当业务扩展的时候注意拆分就行。
3. VO是可以第一个优化掉的，展示业务不复杂的可以压根儿不要，直接用DTO。
4. 这也是最重要的一条，概念是给人用的，多人协作的时候一定要保证大家的概念一致，赶紧把这篇文章转发给跟你协作的人吧。
再附一张参考图
