持久曾设计与ORM笔记

[size=18]持久曾设计与ORM[/size]
ORM概述
ORM可以说是目前比较热点的话题，所谓ORM-Object/Releational Mapper(这里请注意与建模领域中的Object Role Modeling相区分。另外注意这里出现的术语时“O/R Mapper”，而非最常见的“O/R Mapping”。相对来讲，O/R Mapping描述的是一种设计思想或者实现机制，在这一点上，与我们上面所说的“O/R”的含义实际上一致。而“O/R Mapper”一般指 根据O/R原理设计的持久化框架，其中包含了除O/R本身之外的更多内容，如SQL自生成，事务管理，Cache管理等。)，从字面上来理解，即“对象-关系型数据映射组件”。
首先来看O/R，这其中包含两个关键词：Object(对象)和Rational(关系型数据)。在目前的应用系统中，大多数情况下，我们都必须同时面对对象和关系型数据进行开发。
在业务罗辑层和表示层，我们将系统中的各参与失蹄进行面向对象的封装，并籍此将现实世界中的逻辑进行高度抽象后，以计算机语言实现。而另一方面，在数据持久层，迫于目前数据库技术发展的现实，我们必须在现有的关系型数据库模型上进行持久化实现。
一个问题自然浮现，我们应该如何面向对象的设计与传统关系型数据进行整合？
之前讨论“解耦合”思想与DAO模式的时候，实际上我们已经面对这个问题。回忆一下之前的描述：
DAO模式实际上是两个模式的组合，即Data Accessor模式和Active Domain Object模式，其中Data Accessor模式实现了数据访问和业务逻辑的分离，而Active Domain Object实现了业务数据的对象化封装。
在前面的例子中，Customer类，即所谓的Domian Class/Object，对系统中的“用户”对象进行了抽象封装。系统运行过程中，Customer对象实例作为”用户”的抽象代表，扮演着虚拟世界中的一个角色。
同时，在我们的系统中，还需要将Customer实例的信息，也就是所谓的”用户数据”进行持久化，保存到数据库以供日后之用。于是，在上面的就绝方案中，我们引入Data Accessor(数据访问类)，实现对象到关系型数据库之间的持久化。
上述设计中，Customer类的属性信息与数据库表字段之间的对应，也就是O/R关系得一个实例。
从这个简单实例中，我们可以看到，为了实现持久化支持，我们必须编写对应得Data Accessor以实现数据的增删改查(CRUD-Create Retrieve Update Delete)。繁琐的JDBC代码难以避免。
O/R Mapper的出现则解决了这一问题。

持久层实现类型

一般来讲，持久层实现有3种类型。

混杂模式
混杂模式是持久化功能的原始实现模式。即在业务类中混杂JDBC访问代码，从而提供所需的持久化功能。
在前面“解耦合思想的自然演进”一节的第一个实例中，我们已经看到了这样的例子。
业务代码中混杂了基于JDBC编码的持久化实现。
那么，这种方式的持久层实现，这里就称之为混杂模式，如图 [img]http://hiphotos.baidu.com/wanjin/abpic/item/d804e3d3d47bf2dfa8ec9a52.jpg[/img]所示。


这种模式的优点在于开发的迅速便捷。对于原型系统或者小型应用而言显得别具意义。但我们也应该看到，基于这种模式开发的系统，其维护性和扩展性较差，对象属性，数据库结构的变动都将直接导致业务逻辑代码的修改。
实际上，在这种模式中，我们并不能清晰地分辨出所谓“持久层”的逻辑层次。

基于Data Class 的持久层实现模式
在这种模式中，数据类(Data Class) 作为业务类与持久层沟通的桥梁，起着承上起下的作用。
之前所讨论的DAO模式案例，实际上就是这种模式的一个典型实现。Data Class实际上包含了DAO模式中的Domian Class/Object 和Data Accessor Class。
Domian Class作为对现实世界的抽象，起着信息携带者的作用。而Data Accessor Class则通过JDBC代码将 Domian Class与数据库表相关联。

这种模式如图1-10所示。

[img]http://hiphotos.baidu.com/wanjin/abpic/item/b4290ad59f383ec450da4b50.jpg[/img]

在这种模式中，我们实现了业务逻辑与底层数据结构之间的分离。Data Class作为一个相对独立里的逻辑层次，较为清晰的体现了所谓持久层的概念。底层关系数据的结构变化，可以较好地屏蔽在数据类这个层次，从而避免对上层的业务逻辑造成影响。

实际上，目前正在运行的很多Java企业应用系统中，基于这种类型的设计占了很大比重。
而这种模型的缺陷也显而易见，随着设计层次的增多，编码量的增加相当可观。相对第一种混杂模式而言，系统结构上得到较大提升的同时，项目设计和开发成本也相应增高。

繁杂的JDBC代码总得有人去编写，单纯依靠自身力量进行设计和编码，这样的问题难以避免。
所幸，我们不是孤身作战。Sun J2EE 规范制定小组以及开源群体中的众多力量已经深刻的体会到了这一点，于是我们拥有了Entity Bean，JDO，Hibernate，iBatis，Apache OJB
这些杰出的持久层框架。而基于这些成熟可靠的第三方框架，我们得以从设计与工作量之间的平衡难点中解脱。于是，有了下面的第三种解决方案。

基于现有持久层框架的实现模式
实际上，这种模式是第二种模式的延伸。Data Classes所包含的Data Accessor和Domain Class数量并没有减少。
只是，我们把其中最为繁琐的工作——基于JDBC的OR映射工作，交由第三方完成。
Data Accessor中的繁琐编码工作因此得到了空前简化，而与此同时，伴随持久层框架而来的辅助工具也大大减轻了Domain Class的编码负担。
这种实现模式如图1-11所示。
[img] http://hiphotos.baidu.com/wanjin/abpic/item/8e46123be9e02aea14cecb50.jpg[/img]