Java 开发中 PO、VO、TO、BO、DAO、POJO 名词介绍

O/R Mapping 是 Object Relational Mapping（对象关系映射）的缩写。通俗来讲，就是将对象与关系数据库绑定，用对象来表示关系数据。在 O/R Mapping 的世界里，有两个基本且重要的概念需要了解，即 VO 与 PO。

  • VO：值对象（Value Object）
  • PO：持久对象（Persistent Object）

它们均由一组属性及其 getter 和 setter 方法组成。从结构上看，它们并没有什么不同；但从其意义和本质上来看，则是完全不同的。

核心对象详解

以下是 Java 企业级开发中常见对象的详细解释：

1. PO (Persistent Object) 持久对象

  • 定义：在 O/R 映射时出现的概念。如果没有 O/R 映射，这个概念也就不存在了。
  • 对应关系：通常对应数据模型（数据库），可以看成是与数据库中的表相映射的 Java 对象。最简单的 PO 就是对应数据库中某个表中的一条记录，多个记录可以用 PO 的集合。

  • 特性：

    • PO 中应该不包含任何对数据库的操作。
    • PO 是有状态的，每个属性代表其当前的状态。它是物理数据的对象表示。
    • 使用 PO 可以使程序与物理数据解耦，并简化对象数据与物理数据之间的转换。
    • PO 的属性跟数据库表的字段一一对应。
    • PO 对象通常需要实现序列化接口。
    • PO 是向数据库中添加新数据时创建，删除数据库中数据时削除的。它只能存活在一个数据库连接中，断开连接即被销毁。
  • 作用：简化我们对于物理实体的了解和耦合，简单地讲，可以简化对象的数据转换为物理数据的 编程。

2. VO (Value Object / View Object) 值对象 / 视图对象

  • 定义：

    • 值对象：准确来讲，它是业务对象，是存活在业务层的，是业务逻辑使用的。它存活的目的就是为数据提供一个生存的地方。
    • 视图对象：主要对应界面显示的数据对象。对于一个 WEB 页面，或者 SWT、SWING 的一个界面，用一个 VO 对象对应整个界面的值。

  • 特性：

    • VO 是用 new 关键字创建，由 GC 回收的。
    • VO 的属性是根据当前业务的不同而不同的，也就是说，它的每一个属性都一一对应当前业务逻辑所需要的数据的名称。
    • 通常用于业务层之间的数据传递，和 PO 一样也是仅仅包含数据而已。
    • 应是抽象出的业务对象，可以和表对应，也可以不对应，这根据业务的需要。
  • 关系：个人觉得同 DTO（数据传输对象），在 Web 上传递。

3. TO (Transfer Object) / DTO (Data Transfer Object) 数据传输对象

  • 定义：在应用程序不同 tier（层）之间传输的对象。

  • 场景：主要用于远程调用等需要大量传输对象的地方。

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

4. BO (Business Object) 业务对象

  • 定义：从业务模型的角度看，见 UML 元件领域模型中的领域对象。

  • 特性：

    • 封装业务逻辑的 Java 对象。
    • 通过调用 DAO 方法，结合 PO、VO 进行业务操作。
    • 主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。
    • 例如：一个简历，有教育经历、工作经历、社会关系等等。我们可以把教育经历对应一个 PO，工作经历对应一个 PO，社会关系对应一个 PO。建立一个对应简历的 BO 对象处理简历，每个 BO 包含这些 PO。这样处理业务逻辑时，我们就可以针对 BO 去处理。
  • 注意：PO 或叫 BO，与数据库最接近的一层，是 ORM 中的 O。为了同步与 安全 性考虑，最好只给 DAO 或者 Service 调用，而不要用 packcode、backingBean 或者 BO 调。

5. DAO (Data Access Object) 数据访问对象

  • 定义：是一个 Sun 的标准 J2EE 设计模式，这个模式中有个接口就是 DAO，它负责持久层的操作。

  • 特性：

    • 为业务层提供接口。此对象用于访问数据库。
    • 通常和 PO 结合使用，DAO 中包含了各种数据库的操作方法。
    • 通过它的方法，结合 PO 对数据库进行相关的操作。
    • 夹在业务逻辑与数据库资源中间。配合 VO，提供数据库的 CRUD 操作。
  • 关系：和上面几个 O 区别最大，基本没有互相转化的可能性和必要。主要用来封装对数据库的访问。通过它可以把 POJO 持久化为 PO，用 PO 组装出来 VO、DTO。

6. POJO (Plain Ordinary Java Object) 简单 Java 对象

  • 定义：纯的传统意义的 Java 对象。

  • 特性：

    • 在一些 Object/Relation Mapping 工具中，能够做到维护数据库表记录的 persistent object 完全是一个符合 Java Bean 规范的纯 Java 对象，没有增加别的属性和方法。
    • 最基本的 Java Bean，只有属性字段及 setter 和 getter 方法。
    • 个人感觉 POJO 是最常见最多变的对象，是一个中间对象，也是我们最常打交道的对象。

  • 转换关系：

    • 一个 POJO 持久化以后就是 PO。
    • 直接用它传递、传递过程中就是 DTO。
    • 直接用来对应表示层就是 VO。
    • 个人认为 VO 和 PO 应该都属于 POJO 的范畴。

PO 与 VO 的深度对比

虽然 PO 和 VO 在结构上相似，但在本质上有显著区别：

  1. 生命周期：

    • VO：是用 new 关键字创建，由 GC 回收的。
    • PO：则是向数据库中添加新数据时创建，删除数据库中数据时削除的。并且它只能存活在一个数据库连接中，断开连接即被销毁。

  2. 所属层级：

    • VO：是值对象，精确点讲它是业务对象，是存活在业务层的，是业务逻辑使用的。
    • PO：是有状态的，它是物理数据的对象表示。使用它，可以使我们的程序与物理数据解耦。

  3. 属性定义：

    • VO：属性是根据当前业务的不同而不同的，每一个属性都一一对应当前业务逻辑所需要的数据的名称。
    • PO：属性是跟数据库表的字段一一对应的。

相互关系：
PO 和 VO 的关系应该是相互独立的。一个 VO 可以只是 PO 的部分，也可以是多个 PO 构成，同样也可以等同于一个 PO（当然指它们的属性）。正因为这样，PO 独立出来，数据持久层也就独立出来了，它不会受到任何业务的干涉。业务逻辑层也独立开来，它不会受到数据持久层的影响，业务层关心的只是业务逻辑的处理，至于怎么存怎么读交给别人吧！

注：如果没有使用数据持久层，或者说没有使用 Hibernate，那么 PO 和 VO 也可以是同一个东西，虽然这并不好。

架构分层与相关术语

在经典的企业级架构中，还涉及以下分层与术语：

  • 实体 Model：实体模式
  • DAL：数据访问层 (Data Access Layer)
  • IDAL：接口层
  • DALFactory：类工厂
  • BLL：业务逻辑层 (Business Logic Layer)
  • BOF：Business Object Framework，业务对象框架
  • SOA：Service Orient Architecture，面向服务的设计
  • EMF：Eclipse Model Framework，Eclipse 建模框架
  • O/R Mapper：对象/关系映射。定义好所有的 mapping 之后，这个 O/R Mapper 可以帮我们做很多的工作。通过这些 mappings，这个 O/R Mapper 可以生成所有的关于对象保存、删除、读取的 SQL 语句，我们不再需要写那么多行的 DAL 代码了。

框架中的具体实例

  • Struts 里的 ActionForm 就是个 VO。
  • Hibernate 里的 实体 Bean 就是个 PO，也叫 POJO。
  • Hibernate 里的 Criteria 就相当于一个 QO (Query Object，查询对象)。
  • 在使用 Hibernate 的时候我们会定义一些查询的方法，这些方法写在接口里，可以有不同的实现类，而这个接口就可以说是个 DAO。
  • 个人认为 QO 和 DTO 差不多。

总结

  • VO：值对象、视图对象。
  • PO：持久对象。
  • QO：查询对象。
  • DAO：数据访问对象（同时还有 DAO 模式）。
  • DTO：数据传输对象（同时还有 DTO 模式）。
  • BO：业务对象，封装业务逻辑的 Java 对象。

本文转自：http://www.7747.net/kf/201009/74461.html

说明：本文所述概念主要基于经典 J2EE 架构及 SSH（Struts + Spring + Hibernate）开发模式。在现代 Spring Boot 及微服务架构中，部分对象（如 VO 与 DTO）的界限可能趋于模糊，或采用新的命名规范（如 Entity、Model、Response 等），请结合实际技术栈参考使用。