PO、DTO、VO、BO 及其使用场景

基于 说清楚 PO、DTO、VO、BO 与使用场景

简介

• PO（Persistent Object）/DO（Data Object）：此对象与数据库表结构一一对应，通过 DAO 层向上传输数据源对象。
• DTO（Data Transfer Object）：数据传输对象。Service 或 Manager 向外传输的对象。
• BO（Business Object）：业务对象。可以由 Service 层输出的封装业务逻辑的对象。
• VO（View Object）：显示层对象。通常是 Web 向模板渲染引擎层传输的对象。

PO 持久层对象

与数据库的表、视图、或者是查询结果的列一一对应。PO 仅用来展现数据，类中只包含属性和 get/set 方法，而不会有修改数据库的方法。

DAO 层的返回和多参数的接收都是用的 PO 对象封装。

DTO 数据传输对象

DTO 主要是为了解决两个问题：

1. 可以在不同的 Web 服务间传输，因此需要可以序列化，实现 Serializable 接口。
2. 把相关的数据都组合到一个对象中，减少网络调用的次数，从而提高分布式调用的性能和降低网络负载。

在 Dubbo 类型的分布式框架中，微服务间的调用使用 DTO 传输数据也是非常适合的。

但在 Spring Boot、Spring Cloud 框架中，泛指用于 Controller 层与 Service 层之间的数据传输对象。

为什么有了 PO，还要添加一个 DTO？

举个例子，一张数据表中有 100 列，则对应的 PO 同样有 100 个属性。但是，有一个服务调用只需要其中的 10 个属性，此时我们可以创建一个只有 10 个属性的 DTO 返回给调用者。同时也避免了数据表结构给客户端，使用数据表结构和调用结果解偶。

BO 业务对象

封装的复杂对象，主要是对业务数据的封装，可能包含一个或多个其它对象。

BO 包含业务逻辑，如调用 DAO、RPC 等等，负责把 PO 转换为 VO 或 DTO。

BO 和 Service 不同的是，它只包含基本的业务操作；而 Service 负责整个流程，一个业务流程可能会调用到多个 BO。

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

VO 视图对象

VO 用来保存 Web、SWT、Swing、Android、iOS 等一个界面对应的数据，以便显示。

与 DTO 一样，使用 VO 返回给前端，而不是 PO。可以减少数据数据传输，保护表结构和解偶。

VO 和 DTO 比较类似，主要的区别是在设计思想方面。数据是为了在微服务之间传输时，我们使用 DTO；为了返回给 Web、iOS 或者 Android 进行展示时，我们使用 VO。

一点思考

DTO 用在哪里？

建议 DTO 只用来接收其他服务传来的参数。其他服务请求当前服务后，本服务也用 DTO 返回数据。

用什么接收前端传递的 JSON 数据（做 Controller 的参数）？

在一些项目中，会看到使用 VO 接收，因为这两者存在一定联系，比如点击编辑按钮，进入一个表单页，它所展示的内容也许就是它所要保存的内容，所展示的内容是后端通过 VO 传过来的，这时候刚好也可以用 VO 来接收。

但这不适用于所有情况，且随着业务复杂度的提升，很可能会出现 VO 中的字段不再能够满足需求的情况。所以，有的项目中会看到使用 XXRequest、XXParam 或 XXQuery 之类的对象接收 JSON，我觉得这是更合适的做法，同时，注意到并不是所有的 JSON 都是用来做 Query（查询）的，此时建议使用前两种命名，而单独用 XXQuery 来接收查询参数（比如列表页查询）。对应地，有时候会看到项目中有 XXResponse 类，用来作为 Controller 的返回值，其实只是 VO 换了个名字，作用是一样的。

用什么作为 DAO 的多条件参数？

使用 PO，因为 PO 和数据库字段是对应的。但是，有时候会出现连表查询之类的特殊情况，PO 不再满足需求了，需要新加字段，这时候，其实把 PO 添加新字段后的类同样命名为 XXParam 或 XXQuery 是个不错的选择。

用什么作为 DAO 的返回值？

使用 PO，因为 PO 和数据库字段是对应的，DAO 查出的表数据，封装为 PO 返回（当然也可能是 PO List 之类）。但是，有时候会出现连表查询之类的特殊情况，PO 不再满足需求了，需要新加字段，这时候，可以用 VO，因为查询出的数据一般会返回给前端。当然，如果是为了给 BO 赋值，Service 需要用到赋值后的 BO 进行后续操作，那么用 BO 作为返回值也是可以的。

用什么作为 Service 的参数？

Controller 如果需要调用 Service 中的方法，那么直接将其封装了 JSON 数据的参数传给 Service 方法就好，因为 Controller 通常不进行复杂处理，其接收的数据，最终就是给 Service 来处理的。

Service 调用 Service 的情况，如果仅仅是调用 DAO 查数据：

• 可以用 PO，这时该 Service 通常就是调用 DAO 进行查询，而 DAO 使用 PO 接收多条件参数。
• 在查询条件较复杂时，可以将 XXParam 或 XXQuery 传给 DAO 进行查询。

也就是对于单纯调用 DAO 的 Service 方法来说，根据 DAO 所需要的参数接收参数即可。

其他情况个人觉得不必要有太多限制，根据其方法所需的数据，传递对应的参数，可能是上层 Service 收到的参数（比如来自 Controller 的 XXRequest），也可能是上层 Service 参数中的某个属性。

其他服务调用本服务，本服务收到请求后调用 Service 的情况，用 DTO，因为 DTO 用来接收其他服务的请求参数，本服务收到请求后通常最终还是要交给 Service 来处理。

用什么作为 Service 的返回值？

处理其他服务的调用时，返回 DTO。

返回给 Controller，Controller 直接返回 JSON 给前端时，使用 VO/XXResponse。

返回给 Service 时，根据需要返回对应的封装值，比如 BO，或者上层 Service 所需要构建的 VO 的一部分内容。

参考：

（一）应用分层

Controller 接受的参数是 VO 还是 DTO