摘要：说起这个 Java 对象，可真是多的不得了，刚开始学的时候，就被这些 PO、VO、BO 搞得晕头转向，什么玩意儿嘛，后来慢慢才明白一点点，它那个劲头，其实就是为了更好地组织代码。

Java 对象家族：PO、VO、BO 这些"O"， 到底是怎么一回事嘛

说起这个 Java 对象，可真是多的不得了，刚开始学的时候，就被这些 PO、VO、BO 搞得晕头转向，什么玩意儿嘛，后来慢慢才明白一点点，它那个劲头，其实就是为了更好地组织代码。

最开始啊，就得说说那个银行办业务的事儿，你想想啊，柜台小姐姐负责和你聊天，填表，然后后面的后台经理负责处理你的数据，录入系统，这中间肯定有个信息传递的过程吧，柜台小姐姐收集的信息，得告诉后台经理啊，那在软件开发里，就借鉴了这个思路，不同的对象类型，就是为了规范数据在不同层级之间的流转，让代码解耦，复用，各司其职。

所有这些“O”里面啊，就得先提到 POJO，也就是 Plain Old Java Object，这玩意儿说白了最简单了，就是个普通的Java对象，不继承任何特殊的类，也不实现任何特殊的接口，里面就是一些属性和 getter/setter 方法，你想啊，一个用户类 User，里面有 id、name、age 这些属性，这就是个 POJO，其他的“O”啊，都是在这个基础上发展来的。

然后就有了 DAO，Data Access Object，数据访问对象，这个顾名思义，就是用来访问数据的，它代表数据访问层，封装了对数据库的各种操作，增删改查都在这里面，这样做的好处就是，把业务逻辑和数据访问逻辑分开了，以后想换数据库，或者改改数据访问的方式，也不用动业务逻辑的代码，很方便，比如说一个 UserDao 接口，里面有 findById、save 这些方法，UserServiceImpl 通过依赖注入调用 userDao，这就是个典型的 DAO 使用场景。

再说 PO，Persistent Object，持久化对象，这个跟数据库打交道最直接了，它就是带有持久化注解的 Java Bean，跟数据库表字段一一对应，通过 ORM 框架，比如 JPA 或者 MyBatis，就可以把 PO 对象直接映射到数据库里的一条记录，操作 PO 对象，就相当于操作数据库表，比如说用 JPA 注解的 User 类，对应数据库里的 `user` 表，这就是 PO，脸上也有光。

接下来是 DTO，Data Transfer Object，数据传输对象，这个对象是为了在不同层或者不同系统之间传输数据用的，它就是个纯数据对象，不包含任何业务逻辑，它的作用是屏蔽核心领域模型，实现层间解耦，减少网络调用次数，你想啊，注册一个用户，可能只需要用户名、密码、邮箱这些信息，那就可以创建一个 UserRegistrationDTO，只包含这些字段，比完整的 User PO 少很多字段，这样传输起来更快，更安全，再比如，查询用户信息，可能需要组合用户表和部门表的信息，那就可以创建一个 UserProfileDTO，包含用户和部门的相关信息，这都是 DTO 的应用，在 Controller 里面经常会用到 DTO，用来接收前端的请求参数。

VO，Value Object / View Object，值对象或者视图对象，这个对象主要是给 Controller 层和前端交互用的，它的结构是根据前端的需求来定义的，前端需要什么样的数据，VO 就封装成什么样，这样做的好处就是，前端不需要关心后端的业务逻辑，后端也不需要关心前端的具体实现，各司其职，互不干扰，比如说一个 UserVO，可以包含格式化的日期字符串、状态描述等信息，这些信息都是前端需要展示的，它和DTO，有细微差别。

最后就是 BO，Business Object，业务对象，这个对象是 Service 层封装的，它包含复杂的业务逻辑，通常由多个 PO 组合而成，它代表业务领域中的一个整体概念，比如说一个“订单”业务对象，可以包含订单的基本信息（Order PO）、订单项列表（OrderItem PO 集合）、收货地址（Address PO），以及计算总价、检查库存等业务方法，BO 在 Service 层中被组装和使用，用来处理复杂的业务逻辑。

这么一来，PO、VO、BO 这些对象就分工明确了，POJO 是基础，DAO 负责数据访问，PO 负责持久化，DTO 负责数据传输，VO 负责视图展示，BO 负责业务逻辑，每个对象都有自己的作用，组合起来，就构成了一个完整的系统。

现在来总结一下，POJO 就是个普通的 Java 对象，不干啥特殊的事儿，所有层都能用，简单方便，DAO 在数据访问层，负责跟数据库打交道，增删改查都归它管，PO 也在数据访问层，但是它直接跟数据库表映射，带有 JPA 或者 MyBatis 的注解，DTO 在各层之间跑来跑去，负责传输数据，VO 在 Controller 层，专门给前端提供数据，BO 在 Service 层，负责处理复杂的业务逻辑，这下应该清楚了吧。

举个例子你就明白了，假如你要获取 ID 为 1 的用户详情，包括用户的基本信息和部门信息。

首先，前端发起一个 GET 请求，/users/1。

然后，Controller 接收到请求，调用 userService.getUserDetail(1)。

接着，Service 里面，先调用 userDao.findById(1)，返回一个 User PO，再调用 departmentDao.findById(user.getDeptId)，返回一个 Department PO。

最后，Service 把 User PO 和 Department PO 组装成一个 UserDetailDTO 或者 UserDetailVO，或者直接返回一个 UserBO，这取决于业务需求。

Controller 再把 DTO 或者 VO 返回给前端，完事儿，大功告成。

所有人都觉得，这样代码会比较好，可是在那种环境下，谁能受得了，反正我写代码的时候，经常会搞混这些对象，到底该用哪个，有时候也会偷懒，直接用 PO 代替 DTO 或者 VO，虽然也能用，但是总感觉不太规范，以后维护起来也麻烦，特别是团队合作的时候，别人看到你这么写，估计要气得不行。

大家都在想，这到底是怎么一回事，其实就是规范问题，有了这些对象，代码才能更好地组织起来，更容易理解和维护，虽然刚开始学的时候觉得麻烦，但是用久了就习惯了，而且也能体会到它们的好处，大家都在说，这是一个好的习惯。

其实，这些对象也不是一成不变的，根据具体的业务场景，可以灵活调整，比如说，如果一个业务逻辑很简单，直接用 PO 就解决了，那就没必要再创建 BO 了，关键是要理解这些对象的本质作用，然后灵活运用，不要死板地照搬套路，反正我有时候也会根据实际情况，做一些变通，只要能把问题解决就行，很多时候，所谓的“最佳实践”，也只是参考而已，最重要的还是自己的理解和实践。

总的来说，PO、VO、BO 这些 Java 对象，说白了就是为了更好地组织代码，让代码更清晰、更容易维护，理解了它们的作用，就能更好地运用它们，虽然刚开始会觉得有点乱，但是只要多练习，多思考，慢慢就会掌握的，很多人看完这个故事，都会去想，要不要以后试试把这些对象都用起来，说不定能提高自己的代码质量，脸上也有光呢，所有的程序员都会觉得这是一件好事。

来源：职场tan