PO BO VO DTO POJO DAO DO 令人迷惑的Java概念
PO BO VO DTO POJO DAO DO 这些Java中的概念分别指一些什么?
下面内容收集自知乎回答:https://www.zhihu.com/question/39651928
回答一:
POJO PO BO DTO VO 我归在一起,因为PO DTO VO BO 都叫是POJO,就是个简单的java对象;DAO 的话就是进行数据库增删改查的类。
下面重点说下这几个,他们都是POJO:
- PO 持久对象,数据;
- BO 业务对象,封装对象、复杂对象 ,里面可能包含多个类;
- DTO 传输对象,前端调用时传输 ;
- VO 表现对象,前端界面展示。
当你业务足够简单时,一个POJO 也完全当做 PO BO DTO VO 看,下面是例子:
比如有个用户类 只有 name 以及 phone
对于数据库层面也就两列,业务层面,传输,和前台展示时 都只有这两项。
然后说下他们区别开来的例子:
-
还是用户类 name phone 加了个password。
那么你后端的PO属性也是这3个,一般数据库里这个表有几个字段你的PO就有多少属性,但是传输到前台或者展现时,我们不应该把password 密码这种东西也一起传过去,所以他们的DTO VO 就还是 name + phone
- po : name phone password
- dto : name phone
- vo : name phone
-
现在又加了一个 枚举的状态位 status 表示用户的一些特殊状态,前台不会直接显示,可能会根据这个状态产生后续的操作,
- po : name phone password status
- dto : name phone status
- vo : name phone
-
接着看下BO ,一个用户下面 肯定会关联很多其他的表
比如用户设置 用户信息等,那么这个BO 下 不但有用户本身的一些属性,还包含了用户设置 和用户信息这两个类。
其实具体要分到什么程度还是要看项目,很多时候他们其实会没什么区别。
回答二:
缩写的含义:
-
PO 是 Persistant Object 的缩写,用于表示数据库中的一条记录映射成的 java 对象。PO 仅仅用于表示数据,没有任何数据操作。通常遵守 Java Bean 的规范,拥有 getter/setter 方法。
-
DAO 是 Data Access Object 的缩写,用于表示一个数据访问对象。使用 DAO 访问数据库,包括插入、更新、删除、查询等操作,与 PO 一起使用。DAO 一般在持久层,完全封装数据库操作,对外暴露的方法使得上层应用不需要关注数据库相关的任何信息。
-
VO 是 Value Object 的缩写,用于表示一个与前端进行交互的 java 对象。有的朋友也许有疑问,这里可不可以使用 PO 传递数据?实际上,这里的 VO 只包含前端需要展示的数据即可,对于前端不需要的数据,比如数据创建和修改的时间等字段,出于减少传输数据量大小和保护数据库结构不外泄的目的,不应该在 VO 中体现出来。通常遵守 Java Bean 的规范,拥有 getter/setter 方法。
-
DTO 是 Data Transfer Object 的缩写,用于表示一个数据传输对象。DTO 通常用于不同服务或服务不同分层之间的数据传输。DTO 与 VO 概念相似,并且通常情况下字段也基本一致。但 DTO 与 VO 又有一些不同,这个不同主要是设计理念上的,比如 API 服务需要使用的 DTO 就可能与 VO 存在差异。通常遵守 Java Bean 的规范,拥有 getter/setter 方法。
-
BO 是 Business Object 的缩写,用于表示一个业务对象。BO 包括了业务逻辑,常常封装了对 DAO、RPC 等的调用,可以进行 PO 与 VO/DTO 之间的转换。BO 通常位于业务层,要区别于直接对外提供服务的服务层:BO 提供了基本业务单元的基本业务操作,在设计上属于被服务层业务流程调用的对象,一个业务流程可能需要调用多个 BO 来完成。
-
POJO 是 Plain Ordinary Java Object 的缩写,表示一个简单 java 对象。上面说的 PO、VO、DTO 都是典型的 POJO。而 DAO、BO 一般都不是 POJO,只提供一些调用方法。
应用
不同类型的对象在架构设计中用于不同的用途,如下的分层架构表示了各个 POJO 的用途。为什么要在分层架构中,定义这些 POJO 对象呢?主要是为了确保各个分层能够很好地封装自己的服务,有效地控制信息的传播。
试想一下,如果没有 VO 和 PO 的区别,那么数据库表结构的所有字段就一览无余地展示到了前端,给后台安全带来很大的隐患,并且无法在网络传输中剥离冗余信息提高了用户的带宽成本。
实例
以一个实例来探讨下 POJO 的使用。假设我们有一个面试系统,数据库中存储了很多面试题,通过 web 和 API 提供服务。可能会做如下的设计:
数据表:表中的面试题包括 编号、题目、选项、答案、创建时间、修改时间;
PO:包括 编号、题目、选项、答案、创建时间、修改时间;
VO:题目、选项、答案、上一题URL、下一题URL;
DTO:编号、题目、选项、答案、上一题编号、下一题编号;
DAO:数据库增删改查方法;
BO:业务基本操作。
可以看到,进行 POJO 划分后,我们得到了一个设计良好的架构,各层数据对象的修改完全可以控制在有限的范围内。