PO/DO/VO/DTO/BO/POJO概念与区别

2024-01-28 09:53:52

一、PO=DO/VO/DTO/BO/POJO的介绍

PO（Persistent Object）=DO（Data Object）

持久化对象，它跟持久层（通常是关系型数据库）的数据结构形成一一对应的映射关系，如果持久层是关系型数据库，那么，数据表中的每个字段（或若干个）就对应PO的一个（或若干个）属性。通过 DAO 层向上传输数据源对象。

VO(View Object)

视图对象，用于展示层，它的作用是把某个指定页面（或组件）的所有数据封装起来。

简单理解为页面展示用的数据。

DTO（Data Transfer Object）

数据传输对象，Service或Manager向外传输的对象。这个概念来源于J2EE的设计模式，原来的目的是为了EJB的分布式应用提供粗粒度的数据实体，以减少分布式调用的次数，从而提高分布式调用的性能和降低网络负载，但在这里，我泛指用于展示层与服务层之间的数据传输对象。

简单理解，例如一张数据库表有50个字段，那么PO就有50个属性，但是我们在远程服务或者页面显示只需要10个字段。这时就没有必要传输所有的字段，而是用10个属性的DTO来进行传递。

BO（ Business Object）

业务对象。由Service层内封装的临时业务逻辑的对象。通过调用 DAO 方法 , 结合 PO、VO 进行业务操作。一个BO对象可以包括多个PO对象。如常见的工作简历例子为例，简历可以理解为一个BO，简历又包括工作经历，学习经历等，这些可以理解为一个个的PO，由多个PO组成BO。复杂例子PO1是交易记录，PO2是登录记录，PO3是商品浏览记录，PO4是添加购物车记录，PO5是搜索记录，BO是个人网站行为对象。

BO是一个业务对象，一类业务就会对应一个BO，数量上没有限制，而且BO会有很多业务操作，也就是说除了get，set方法以外，BO会有很多针对自身数据进行计算的方法。

现在很多持久层框架自身就提供了数据组合的功能，因此BO有可能是在业务层由业务来拼装PO而成，也有可能是在数据库访问层由框架直接生成。很多情况下为了追求查询的效率，框架跳过PO直接生成BO的情况非常普遍，PO只是用来增删改使用。（左边这句话，？，真的会这么做吗？）

POJO（ Plain Ordinary Java Object）

专指只有setter/getter/toString的简单类，包括DO/DTO/BO/VO等。

POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。

大致的示例代码

Controller层：public List<UserVO> getUsers(UserQuery userQuery)。此层常见的转换为：DTO转VO
- Query:数据查询对象，各层接收上层的查询请求。注意超过 2 个参数的查询封装，禁止使用 Map 类来传输。
Service/Manager层：List<UserDTO> getUsers(UserQuery userQuery)。然后在Service内部使用UserBO封装中间所需的逻辑对象，此层常见的转换为：PO转DTO，或PO转BO转DTO
DAO层：List<UserPO> getUsers(UserQuery userQuery);

二、区别

2.1 VO和DTO的区别与应用

VO和DTO的区别

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

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

理论归理论，这到底还是分析设计层面的思维，是否在实现层面必须这样做呢？一刀切的做法往往会得不偿失，下面我马上会分析应用中如何做出正确的选择。

VO与DTO的应用

上面只是用了一个简单的例子来说明VO与DTO在概念上的区别，本节将会告诉你如何在应用中做出正确的选择。

在以下才场景中，我们可以考虑把VO与DTO二合为一（注意：是实现层面）：

当需求非常清晰稳定，而且客户端很明确只有一个的时候，没有必要把VO和DTO区分开来，这时候VO可以退隐，用一个DTO即可，为什么是VO退隐而不是DTO？回到设计层面，服务层的职责依然不应该与展示层耦合，所以，对于前面的例子，你很容易理解，DTO对于“性别”来说，依然不能用“帅哥美女”，这个转换应该依赖于页面的脚本（如JavaScript）或其他机制（JSTL、EL、CSS）
即使客户端可以进行定制，或者存在多个不同的客户端，如果客户端能够用某种技术（脚本或其他机制）实现转换，同样可以让VO退隐

以下场景需要优先考虑VO、DTO并存：

上述场景的反面场景
因为某种技术原因，比如某个框架（如Flex）提供自动把POJO转换为UI中某些Field时，可以考虑在实现层面定义出VO，这个权衡完全取决于使用框架的自动转换能力带来的开发和维护效率提升与设计多一个VO所多做的事情带来的开发和维护效率的下降之间的比对。
如果页面出现一个“大视图”，而组成这个大视图的所有数据需要调用多个服务，返回多个DTO来组装（当然，这同样可以通过服务层提供一次性返回一个大视图的DTO来取代，但在服务层提供一个这样的方法是否合适，需要在设计层面进行权衡）。

2.2 BO和DTO的区别

这两个的区别主要是就是字段的删减。

BO对内，为了进行业务计算需要辅助数据，或者是一个业务有多个对外的接口，BO可能会含有很多接口对外所不需要的数据，因此DTO需要在BO的基础上，只要自己需要的数据，然后对外提供。

在这个关系上，通常不会有数据内容的变化，内容变化要么在BO内部业务计算的时候完成，要么在解释VO的时候完成。

三、相关的代码规范：

命名风格

【强制】类名使用 UpperCamelCase 风格，必须遵从驼峰形式，但以下情形例外:DO / BO /DTO / VO / AO 正例:MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion 反例:macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion

【参考】各层命名规约:

A）Service/DAO层方法命名规约
- 1) 获取单个对象的方法用get做前缀。
- 2) 获取多个对象的方法用list做前缀。
- 3) 获取统计值的方法用count做前缀。
- 4) 插入的方法用save/insert做前缀。
- 5) 删除的方法用remove/delete做前缀。
- 6) 修改的方法用update做前缀。

B）领域模型命名规约
- 1) 数据对象:xxxDO，xxx即为数据表名。
- 2) 数据传输对象:xxxDTO，xxx为业务领域相关的名称。
- 3) 展示对象:xxxVO，xxx一般为网页名称。
- 4) POJO是DO/DTO/BO/VO的统称，禁止命名成xxxPOJO。

OOP 规约

【强制】定义 DO/DTO/VO 等 POJO 类时，不要设定任何属性默认值。

反例:POJO类的 addTime 默认值为new Date(); 但是这个属性在数据提取时并没有置入具体值，在更新其它字段时又附带更新了此字段，导致创建时间被修改成当前时间。

参考资料

https://www.cnblogs.com/qixuejia/p/4390086.html

https://zhuanlan.zhihu.com/p/102389552

码农公寓