Java —— 常见对象类型简写及意义

1、PO（Persistant Object）

持久对象，PO仅仅用于表示数据，除了getter/setter，没有其他数据操作。

可以用于表示数据库中的一条记录映射成的Java对象。

2、VO (View Object)

视图对象，VO用于在控制层(Controller)与视图层(前端页面)进行传输交换。

例如前端登陆需要用户名、密码、验证码信息，而用户表中记录除了前面提到的三项还有性别、昵称等字段，

VO则只声明了登陆所需的三个字段，PO则声明了整个表的所有字段，可以减少传输数据量大小和保护数据库结构不外泄。

3、AO (Application Obejct)

应用对象。 在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。

4、BO (Business Object)

业务对象，通常位于中间层。主要作用是把业务逻辑封装为一个对象，这个对象可以包括一个或多个其它的对象。

比如一个简历，有教育经历、工作经历、社会关系等等。
我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。
建立一个对应简历的BO对象处理简历，每个BO包含这些PO。
这样处理业务逻辑时，我们就可以针对BO去处理。

5、DO (Domain Object)

领域对象，就是从现实世界中抽象出来的有形或无形的业务实体。

6、DTO (Data Transfer Object)

数据传输对象，Service或Manager向外传输的对象。

比如我们一张表有100个字段，那么对应的PO就有100个属性。但是我们界面上只要显示10个字段，客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO.

DTO与VO区别：

既然DTO是展示层与服务层之间传递数据的对象，为什么还需要一个VO呢？对！对于绝大部分的应用场景来说，DTO和VO的属性值基本是一致的，而且他们通常都是POJO，因此没必要多此一举，但不要忘记这是实现层面的思维，对于设计层面来说，概念上还是应该存在VO和DTO，因为两者有着本质的区别，DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。

用一个例子来说明可能会比较容易理解：

例如Service层有一个getUser的方法返回一个系统用户，其中有一个属性是gender(性别)，对于Service层来说，它只从语义上定义：1-男性，2-女性，0-未指定，而对于展示层来说，它可能需要用“帅哥”代表男性，用“美女”代表女性，用“秘密”代表未指定。说到这里，可能你还会反驳，在服务层直接就返回“帅哥美女”不就行了吗？对于大部分应用来说，这不是问题，但设想一下，如果需求允许客户可以定制风格，而不同风格对于“性别”的表现方式不一样，又或者这个服务同时供多个客户端使用（不同门户），而不同的客户端对于表现层的要求有所不同，那么，问题就来了。再者，回到设计层面上分析，从职责单一原则来看，服务层只负责业务，与具体的表现形式无关，因此，它返回的DTO，不应该出现与表现形式的耦合。

7、DAO(Data access object)

数据访问对象，它是一个面向对象的数据库接口，负责持久层的操作，为业务层提供接口，主要用来封装对数据库的访问，常见操作无外乎 CURD。

比如Mybatis的mapper。

8、POJO (Plain Ordinary Java Object)

普通Java对象，Java对象类应用在不同的地方就是不同的对象。
用于传输就是DTO，用于视图就是VO，用于持久化记录就是PO。

参考:
https://blog.csdn.net/uestcyms/article/details/80244407
https://www.cnblogs.com/x-zhoulin/p/11364676.html
https://blog.csdn.net/yu1014745867/article/details/89218322