概念不清，会很影响开发中的逻辑性和条理性，进而影响接口设计，代码编写的质量。
网络上大家对这些个概念的探究很多，但终究没有一个统一的说法。
不论哪家解释，我觉得最重要的是： 1）词汇之间的解释统一； 2）词汇之间的联系不冲突，能自圆其说，自成一体。
在自己初步探索后，个人更认同这样的理念(如下)。
若读者凑巧阅读到本文，欢迎一起探讨。
1 POJO := Plain Ordinary Java Object
POJO := Plain Ordinary Java Object
简单的Java对象
POJO ⊇ { PO, DTO, VO }
PO := Persistent Object
持久对象
用途: 用于表示数据库中的一条记录，映射成Java对象
PO仅用于表示数据库数据，无任何其它的数据操作
DTO := Data Transfer Object
数据传输对象
用途: DTO通常用于【不同Web服务之间(RestFul / RPC调用 / WebService调用等)】或【同一服务的不同分层之间的数据传输】 ； 减小数据传输量
一个DTO可以对应多个从存储层返回的PO（Persistent Object）的json数组，这里可以使用AutoMapper来进行自适配。
- DTO存在的必要性
DTO不是为MVC的视图而存在的模型，而是为了适应来自前端请求而存在的。
DTO模型把来自前端的请求(这个请求不管来自前后端分离的页面，还是mvc的视图页面)封装在DTO模型中，然后服务端处理转换成Entity Framework中的PO模型。
VO := View Object(个人更认同) := Value Object
视图对象/值对象
VO for request and response of users or controller layers
用途: 用于表示一个与前端交互的Java对象；用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。
举例：展示层将DTO传送过来男性显示成帅哥（客户端1），或者显示成靓仔（客户端2）；将帅哥或者靓仔，转换成男性，以DTO形式请求服务端。
视图模型VO可以对应客户端的网页显示，同样的DTO比如性别男，可以对应多个VO进行显示，即可以对应多个客户端，比如VO1把性别男显示成帅哥，VO2把性别男显示成靓仔等等。
- 视图对象存在的必要性/ VO VS DTO
如果是一个DTO对应一个VO，则DTO=VO;
但是如果一个DTO对应多个VO，则展示层需要把VO转换为服务层对应方法所要求的DTO，传送给服务层。
从而达到服务层与展示层解耦的效果。
- VO VS PO:
PO: 纯数据库表记录的完全映射；
VO: 仅包含前端需要展示的数据/属性;(需要对前端/用户屏蔽部分字段；减小数据传输量)
2 BO/DO := Business Object / Domain Object
BO/DO := Business Object / Domain Object
业务对象/领域对象
BO 包含了业务逻辑，常封装了对DAO，RPC等的调用；
可进行PO，VO，DTO之间的转换；
通常属于业务层，但要区别于直接对外提供服务的服务层；
BO提供基本业务单元的基本业务操作，在设计上属于被服务层业务流程调用的对象，一个业务流程可能需要调用多个BO来完成
3 DAO
Database Access Object
数据库访问对象
用途: 用DAO访问数据库，包括增删查改等操作；同POJO一起使用
4 小结
来源网络，并非权威，仅供参考
假定: 我们有一个面试系统，数据库中存储了很多面试题，通过 web 和 API 提供服务。可能会做如下的设计：
- 数据库表：面试题{编号(ID)、题目(Question)、选项(OPTIONS)、答案(ANSWER)、创建时间(CREATE_TIME)、修改时间(UPDATE_TIME)}
- PO：{ 题目、选项、答案、创建时间、修改时间 }
- VO：{ 题目、选项、答案、上一题URL、下一题URL }
- DTO：{ 编号、题目、选项、答案、上一题编号、下一题编号 }
- DAO：{ methods增、methods删、methods改、methods查 }
- BO：{ #业务基本操作# }