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
带有 J2EE 的 Enterprise Java Bean (EJB) 以实体 bean 的形式在 Java 持久性领域带来了一些新变化。 这个想法是将开发人员与直接干预数据库持久性的复杂性隔离开来。 它引入了一种基于接口的方法。 有一个专门的 bean 编译器来生成持久性、事务管理和业务逻辑委托的实现。 专门的 XML 部署描述符用于配置实体 bean。 问题在于 EJB 并没有简化事情，而是包含了很多复杂性。 结果，尽管随后进行了许多改进，例如引入了 Enterprise JavaBeans 查询语言 (EJB QL)，但它很快就失去了人气。
发表评论 取消回复