JSP企业网站建设 第2页
理解对象-关系持续性
我们工作的每个软件项目工程中，管理持续性数据的方法已经成为一项关键的设计决定。对于Java应用，持续性数据并不是一个新的或不寻常的需求，你也许曾经期望能够在许多相似的，已被很好构建的持续性解决方案中简单地进行选择。考虑一下Web应用框架(Jakarta Struts 对 WebWork)，GUI组件框架（Swing 对 SWT），或模版工具（JSP 对 Velocity）。每一种相互竞争的解决方案都有其优缺点，但它们至少都共享了相同的范围与总体的方法。不幸的是，这还不是持续性技术的情形，对持续性技术相同的问题有许多不同的混乱的解决方案。
在过去的几年里，持续性已经成为Java社区里一个争论的热点话题。对这个问题的范围许多开发者的意见甚至还不一致。持续性还是一个问题吗？它早已被关系技术与其扩展例如存储过程解决了。或者它是一个更一般的问题，必须使用特殊的Java组件模型例如EJB实体Bean来处理？甚至SQL和JDBC中最基本的CRUD（create, read, update, delete）操作也需要进行手工编码，还是让这些工作自动化？如果每一种数据库管理系统都有它自己的方言，我们如何达到可移植性？我们应该完全放弃SQL并采用一种新的数据库技术，例如面向对象数据库系统吗？争论仍在继续，但是最近一种称作对象-关系映射（ORM）的解决方案逐渐地被接受。Hibernate就是这样一种开源的ORM实现。
Hibernate是一个雄心勃勃的项目，它的目标是成为Java中管理持续性数据问题的一种完整的解决方案。它协调应用与关系数据库的交互，让开发者解放出来专注于手中的业务问题。Hibernate是一种非强迫性的解决方案。我们的意思是指在写业务逻辑与持续性类时，你不会被要求遵循许多Hibernate特定的规则和设计模式。这样，Hibernate就可以与大多数新的和现有的应用平稳地集成，而不需要对应用的其余部分作破坏性的改动。
本篇文章是关于Hibernate的。我们包含了基本与高级的特征，并且描述了许多使用Hibernate开发新应用时的推荐方式。通常这些推荐并不特定于Hibernate——有时它们可能是我们关于使用持续性数据工作时处理事情的最佳方式的一些想法，只不过在Hibernate的环境中进行了介绍。然而，在我们可以开始使用Hibernate之前，你需要理解对象持续性和对象-关系映射的核心问题。本章解释了为什么像Hibernate这样的工具是必需的。
首先，我们定义了在面向对象的应用环境中持续性数据的管理，并且讨论了SQL，JDBC和Java的关系，Hibernate就是在这些基础的技术与标准之上构建的。然后我们讨论了所谓的对象-关系范例不匹配的问题和使用关系数据库进行面向对象的软件开发中所遇到的一些一般性的问题。随着这个问题列表的增长，我们需要一些工具与模式来最小化我们用在与持续性有关的代码上的时间就变得很明显了。在我们查看了可选的工具和持续性机制后，你会发现ORM在许多情况下可能是最好的解决方案。我们关于ORM的优缺点的讨论给了你一个完整的背景，在你为自己的项目选择持续性解决方案时可以作出最好的决定。
什么是持续性？
几乎所有的应用都需要持续性数据。持续性在应用开发中是一个基本的概念。如果当主机停电时一个信息系统没有保存用户输入的数据，这样的系统几乎没有实际的用途。当我们讨论Java中的持续性时，我们通常是指使用SQL存储在关系数据库中的数据。我们从简单地查看一下这项技术和我们如何在Java中使用它开始。具有了这些知识之后，我们继续关于持续性的讨论以及如何在面向对象的应用中实现它。
关系数据库
你，像许多其他的开发者，很可能在使用一个关系数据库进行工作。实际上，我们中的大多数每天都在使用关系数据库。关系技术是一个已知数。仅此一点就是许多组织选择它的一个充分的理由。但仅仅这样说就有点欠考虑了。关系数据库如此不易改变不是因为偶然的原因而是因为它们那令人难以置信的灵活与健壮的数据管理方法。
关系数据库管理系统既不特定于Java，也不特定于特殊的应用。关系技术提供了一种在不同的应用或者相同应用的不同技术（例如事务工具与报表工具）之间共享数据的方式。关系技术是多种不同的系统与技术平台之间的一个共同特征。因此，关系数据模型通常是业务实体共同的企业级表示。关系数据库管理系统具有基于SQL的应用编程接口，因此我们称今天的关系数据库产品为SQL数据库管理系统，或者当我们讨论特定系统时，称之为SQL数据库。
理解SQL
为了有效地使用Hibernate，对关系模型和SQL扎实的理解是前提条件。你需要用你的SQL知识来调节你的Hibernate应用的性能。Hibernate会自动化许多重复的编码任务，如果你想利用现代SQL数据库的全部能力,你的持续性技术的知识必须扩充至超过Hibernate本身。记住基本目标是健壮地有效地管理持续性数据。
让我们回顾一些本书中用到的SQL术语。你使用SQL作为数据定义语言（DDL）通过CREATE与ALTER命令来创建数据库模式。创建了表（索引，序列等等）之后，你又将SQL作为数据处理语言（DML）来使用。使用DML，你执行SQL操作来处理与取出数据。处理操作包括插入，更新和删除。你使用约束，投射，和连接操作（包括笛卡尔积）执行查询来取出数据。为了有效地生成报表，你以任意的方式使用SQL来分组，排序和合计数据。你甚至可以相互嵌套SQL命令，这项技术被称作子查询。你也许已经使用了多年的SQL并且非常熟悉用它编写的基本操作和命令。尽管如此，我们的经验还是告诉我们SQL有时难于记忆并且有些术语有不同的用法。为了理解本书，我们不得不使用相同的术语与概念；因此，如果我们提到的任何术语是新出
现的或者是不清楚的。 为了进行健全的Java数据库应用开发，SQL知识是强制的。如果你需要更多的资料，找一本Dan Tow的优秀著作《SQL Tuning》。同时读一下《An Introduction to Database Systems》，学习一些（关系）数据库系统的理论，概念和思想。关系数据库是ORM的一部分，当然另一部分由你的Java应用中的对象构成，它们需要使用SQL被持续化到数据库中。
在Java中使用SQL
当你在Java应用中使用SQL工作时，Java代码通过Java数据库连接（JDBC）执行SQL命令来操作数据库。SQL可能被手工编码并嵌入到Java代码中，或者可能被匆忙地通过Java代码生成。你使用JDBC API将变量绑定到查询参数上，开始执行查询，在查询结果表上滚动，从结果集中取出值，等等。这些都是底层的数据访问任务，作为应用开发者，我们对需要这些数据访问的业务问题更加感兴趣。需要我们自己来关心这些单调的机械的细节，好像并不是确定无疑的。
我们真正想做的是能够编写保存和取出复杂对象（我们的类实例）的代码—从数据库中取出或者保存到数据库中，尽量为我们减少这些底层的苦差事。因为这些数据访问任务通常都是非常单调的，我们不禁要问：关系数据模型特别是SQL是面向对象的应用中持续性问题的正确选择吗？我们可以立即回答这个问题：是的！有许多原因使SQL数据库支配了计算行业。关系数据库管理系统是唯一被证明了的数据管理技术并且几乎在任何Java项目中都是一项需求。
然而，在过去的15年里，开发者一直在讨论范例不匹配的问题。这种不匹配解释了为什么每个企业项目都需要在持续性相关的问题上付出如此巨大的努力。这里所说的范例是指对象模型和关系模型，或者可能是面向对象编程与SQL。让我们通过询问在面向对象的应用开发环境中，持续性究竟意味着什么，来开始我们对不匹配问题的探究。首先，我们将本章开始部分声明的对持续性过分简单的定义扩展到一个较宽的范围，更成熟的理解包括文护与使用持续性数据。
面向对象应用中的持续性
在面向对象的应用中，持续性允许一个对象的寿命可以超过创建它的程序。这个对象的状态可能被存储到磁盘上，并且在将来的某一时刻相同状态的对象可以被重新创建。这样的应用不仅仅限于简单的对象——关联对象的完整图形也可以被持续化并且以后可以在新的进程里被重新创建。大多数对象并不是持续性的；暂态对象只有有限的寿命，被实例化它的进程的寿命所限定。几乎所有的Java应用都在混合使用持续与暂态对象；因此，我们需要一个子系统来管理我们的持续性数据。现代的关系数据库为持续性数据提供了一种结构化的表示方法，允许排序，检索和合计数据。数据库管理系统负责管理并发性和数据的完整性；它们负责在多个用户和多个应用之间共享数据。数据库管理系统也提供了数据级别的安全性。当我们在本书中讨论持续性时，我们考虑以下这些事情：
■ 存储，组织与恢复结构化数据
■ 并发性与数据完整性
■ 数据共享
特别地，我们将在使用域模型的面向对象的应用环境中考虑这些问题。使用域模型的应用并不直接使用业务实体的扁平表示进行工作，这些应用有它们自己的面向对象的业务实体模型。如果数据库中有“项目”与“竞价”表，则在这些Java应用中会定义“项目”与“竞价”类。
然后，业务逻辑并不直接在SQL结果集的行与列上进行工作，而是与面向对象的域模型进行交互，域模型在运行时表现为一个关联对象的交互图。业务逻辑从不在数据库中（作为SQL存储过程）执行，而是被实现在Java程序中。这就允许业务逻辑使用成熟的面向对象的概念，例如继承与多态。我们可以使用众所周知的设计模式例如“策略”，“中介者”和“组合” ，所有这些模式都依赖于多态方法调用。现在给你一个警告：并不是所有的Java应用都是按照这种方式设计的，并且也不打算是。对于简单的应用不使用域模型可能会更好。SQL和JDBC API可以完美地处理纯扁平数据，并且现在新的JDBC结果集已经使CRUD操作变得更简单了。使用持续性数据的扁平表示进行工作可能更直接并且更容易理解。
然而，对于含有复杂业务逻辑的应用，域模型有助于有效地提高代码的可重用性和可文护性。在本书中我们集中在使用域模型的应用上，因为通常Hibernate和ORM总是与这种类型的应用有关。如果我们再次考虑SQL和关系数据库，我们最终会发现这两种范例的不匹配之处。
SQL操作例如投射与连接经常会导致对结果数据的扁平表示。这与在Java应用中用来执行业务逻辑的关联对象的表示完全不同！这是根本不同的模型，而不仅仅是相同模型的不同的显示方式。
带着这些认识，我们能够开始看一下这些问题——许多已经很好理解的与没有很好理解的——必须被合并使用这两种数据表示的应用所解决——一个面向对象的域模型与一个持续性的关系模型。让我们仔细地看一下。
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] ... 下一页 >>