|Java:使用 JPA 了解 Java 对持久性的支持

|Java:使用 JPA 了解 Java 对持久性的支持

Java 平台已经有标准的 API 以 JDBC API 的形式与数据库系统一起工作 。 这些 API 非常擅长使用数据库 , 并提供了从 Java 语言方便地与数据库交互所需的方法 。

但是 , 问题在于 Java 是一种面向对象的语言 。JDBC提供了数据库交互的核心API , 并不专注于将数据库表的行列结构转化为实体类 。 因此 , 需要在 JDBC API 之上工作的 API 层 。 持久性 API 或 JPA 缓解了两种架构上不同的模型 , 目的是利用操作的流动性 。API 有助于将数据库关系表表示为 POJO , 并且可以通过 Java 代码以类似的方式处理 。 核心 JDBC API 在后台工作以处理复杂的通信和数据库连接 , 而 JPA 使处理能够根据 Java 语言的面向对象代码完成 。 然而 , 关系数据库和Java之间的数据映射并不是一件容易的事 。
Java 持久性支持
在典型的关系数据库中 , 信息以行列结构存储 。 数据库系统和 Java 应用程序的对象模型之间的数据交换很困难 , 因为 Java 将单个实体指定为由一组属性和应用于它们的操作表示的类 。 因此 , 为了使两种不同架构之间的行为不匹配 , Java 程序员必须编写多行代码 。 这些代码行有助于将数据库表的行和列数据转换为 Java 对象 。 但是 , 这些代码行经常变得过于重复 , 导致源代码充满了样板代码 。 这是不可取的 , 并且违反了基本的面向对象的可重用性原则 。 尽管聪明的代码可以减轻许多逆境 , 但这并不是一个简单的解决方案 。

第三方解决方案的出现为将数据库数据映射到 Java 对象提供了喘息的机会 , 但它们并不标准 。 每个供应商的实现都大相径庭 。 这一切都意味着这种情况需要 Java 平台本身提供标准的持久性 API 库 。 这导致了 Java Persistence API (JPA) 的引入 , 特别是在 Java 的面向对象领域模型和数据库系统之间架起了一座桥梁 。
专有解决方案
数据映射器
数据映射器基本上是 Martin Fowler 在其 2003 年的企业应用程序架构模式一书中提出的架构模式 。 它提供了解决对象关系问题的部分方法 。 映射器有助于创建一种策略 , 该策略属于普通 JDBC 和全功能对象关系映射解决方案之间的类别 。 在这里 , 应用程序开发人员使用数据映射器方法创建原始 SQL 字符串以将数据库表映射到 Java 对象 。 有一个流行的框架使用这种 SQL 数据库和 Java 对象之间的映射技术 , 称为 Apache iBatis 。Apache iBatis 项目现在已被宣布为非活动状态 。 但是 , Apache iBatis 的原始创建者已将该项目转移到 MyBatis 并正在积极开发中 。
与使用 MyBatis 等数据映射器框架的其他对象关系问题解决方案不同 , 我们可以完全控制与数据库的 SQL 事务 。 它是一个轻量级的解决方案 , 不承担成熟 ORM 框架的开销 。 但是 , 数据映射器存在问题 。 对对象模型所做的任何更改都会对数据模型产生影响 。 因此 , 必须直接对 SQL 语句进行重大更改 。 该框架的简约特性可帮助开发人员根据需要合并新的更改和修改 。 数据映射器在我们需要最小框架、显式 SQL 处理以及对开发人员修改进行更多控制的情况下特别有用 。
JDBC
JDBC(Java 数据库连接)是 Microsoft 的 ODBC(对象数据库连接)规范的 Java 特定版本 。ODBC 是用于连接来自任何语言或平台的任何关系数据库的标准 。JDBC 提供了与 Java 语言类似的抽象 。JDBC 使用 SQL 与数据库进行交互 。 开发人员必须根据后端数据库的语法规范编写 DDL 或 DML 查询 , 但使用 Java 编程模型处理它们 。Java 源代码和 SQL 语句之间存在紧密耦合 。 我们可以使用原始 SQL 语句并根据需要静态地操作它们 。 由于其静态性质 , 很难合并更改 。 此外 , SQL 方言因数据库供应商而异 。JDBC 硬连线到数据库而不是 Java 语言的对象模型 。 因此 , 使用它很快就会觉得很麻烦 , 尤其是当来自 Java 源代码的数据库交互增加时 。 但是 , JDBC 是 Java 中对数据库持久性的主要支持 , 并构成了高级框架的基础 。
EJB
【|Java:使用 JPA 了解 Java 对持久性的支持】带有 J2EE 的 Enterprise Java Bean (EJB) 以实体 bean 的形式在 Java 持久性领域带来了一些新变化 。这个想法是将开发人员与直接干预数据库持久性的复杂性隔离开来 。它引入了一种基于接口的方法 。有一个专门的 bean 编译器来生成持久性、事务管理和业务逻辑委托的实现 。专门的 XML 部署描述符用于配置实体 bean 。问题在于 EJB 并没有简化事情 , 而是包含了很多复杂性 。结果 , 尽管随后进行了许多改进 , 例如引入了 Enterprise JavaBeans 查询语言 (EJB QL) , 但它很快就失去了人气 。