一、前言
Hibernate和Spring是两个著名的开源框架,越来越广泛地 应用于J2EE应用程序的开发中。虽然它们各自所针对的目标不同,但是它们都有一个共同的特点:依赖性映射。Spring注重于在把对象返回到客户之前,帮助挑选出对象间的依赖性,这样以来大大减少了客户端的编码工作。Hibernate则专注于在把完整的对象模型返回到客户之前,挑选出对象模型描述的依赖性。当直接使用JDBC来把一个数据模型映射成一个对象模型时,我们通常需要 编写大量的代码来建造一个对象模型。Hibernate可以帮助消除这种大部分的编码工作。
Hibernate 2.x提供了基本的表到对象的映射,正常的关联映射(包括一对一,一对多和 多对多关系),多态映射,等等。Hibernate 3.x把这种技术又推进了一层-通过使用规则、过滤、子选择等等来加强映射的灵活性-它们提供了良好粒度的解释特性。
在本文中,我们将向你展示规则的各种不同特性是怎样帮助实现模型转换的。在Hibernate 3.x之前,规则属性只能出现在一个property元素中。虽然你还可以这样做,但是,Hibernate 3.x提供了一个规则属性或元素(其实,在涉及到规则使用时,这两者是等价的),它可以应用在许多元素中,包括discriminator,many-to-one,one-to-one,element,many-to-many,map-key,map-key-many-to-many以及property。这加强了对象-关系(O-R)映射的灵活性,并因此允许对更复杂的数据模型的良好粒度解释。
大致上有两种场合下,必须使用规则:
1. 需要规则计算结果的场所。与元素discriminator,element,map-key,map-key-many-to-many及property等一起使用的规则属于这一类型。
2. 借助于规则的帮助实现联结之目的。与元素many-to-one,one-to-one及many-to-many等一起使用的规则属于这一类型。
二、类型1:取得一个规则的计算结果
(一) Discriminator
在实际的数据模式中,经常有用一个表来描述另外一个表的情况。规则有助于在O-R映射中实现灵活的 多态性。
在图1所示的例子中,共有两个表: Product和ProductRelease。每个产品记录都有一个ProductReleaseID,用于参照它相应的产品发行记录,包括产品发行名、类型、发行日期等。
在ProductRelease表中一个有趣的属性是SubProductAllowable,其值可以是0或1。值1意味着任何该产品的发行都可以有相应的子产品,而值0意味着不允许有子产品。例如,一些产品由多种子产品配置而成,而一些产品只能是其自身。
图2显示了一个从该数据模型解释出来的对象模型。其中,嵌套接口定义了getSubProducts和setSubProducts方法。类NestedProduct扩展了基类Product并实现了嵌套接口。一条产品数据记录是属于Product还是属于NestedProduct依赖于它相应的产品发行记录的SubProductAllowable的值。
为了成功完成这个模型转化,我们使用了一个Hibernate3.x映射,如下:
如果规则表达式计算结果是0-也就是说,不允许有相应的子产品-那么该对象将是类Product。如果结果是1,该对象将是一个NestedProduct。在表1和表2中,对于Product表中的第一个记录(ProductID=10000001),初始化类将是一个NestedProduct,因为它通过SubProductAllowable=1参考引用一个ProductRelease记录。对于Product表中的第二个记录(ProductID=20000001),初始化类将是Product,因为它通过SubProductAllowable=0参考引用一个ProductRelease记录。
表格1.表ProductRelease中的记录
表格2.表Product中的记录
Hibernate和Spring是两个著名的开源框架,越来越广泛地 应用于J2EE应用程序的开发中。虽然它们各自所针对的目标不同,但是它们都有一个共同的特点:依赖性映射。Spring注重于在把对象返回到客户之前,帮助挑选出对象间的依赖性,这样以来大大减少了客户端的编码工作。Hibernate则专注于在把完整的对象模型返回到客户之前,挑选出对象模型描述的依赖性。当直接使用JDBC来把一个数据模型映射成一个对象模型时,我们通常需要 编写大量的代码来建造一个对象模型。Hibernate可以帮助消除这种大部分的编码工作。
Hibernate 2.x提供了基本的表到对象的映射,正常的关联映射(包括一对一,一对多和 多对多关系),多态映射,等等。Hibernate 3.x把这种技术又推进了一层-通过使用规则、过滤、子选择等等来加强映射的灵活性-它们提供了良好粒度的解释特性。
在本文中,我们将向你展示规则的各种不同特性是怎样帮助实现模型转换的。在Hibernate 3.x之前,规则属性只能出现在一个property元素中。虽然你还可以这样做,但是,Hibernate 3.x提供了一个规则属性或元素(其实,在涉及到规则使用时,这两者是等价的),它可以应用在许多元素中,包括discriminator,many-to-one,one-to-one,element,many-to-many,map-key,map-key-many-to-many以及property。这加强了对象-关系(O-R)映射的灵活性,并因此允许对更复杂的数据模型的良好粒度解释。
大致上有两种场合下,必须使用规则:
1. 需要规则计算结果的场所。与元素discriminator,element,map-key,map-key-many-to-many及property等一起使用的规则属于这一类型。
2. 借助于规则的帮助实现联结之目的。与元素many-to-one,one-to-one及many-to-many等一起使用的规则属于这一类型。
二、类型1:取得一个规则的计算结果
(一) Discriminator
在实际的数据模式中,经常有用一个表来描述另外一个表的情况。规则有助于在O-R映射中实现灵活的 多态性。
在图1所示的例子中,共有两个表: Product和ProductRelease。每个产品记录都有一个ProductReleaseID,用于参照它相应的产品发行记录,包括产品发行名、类型、发行日期等。
在ProductRelease表中一个有趣的属性是SubProductAllowable,其值可以是0或1。值1意味着任何该产品的发行都可以有相应的子产品,而值0意味着不允许有子产品。例如,一些产品由多种子产品配置而成,而一些产品只能是其自身。
图2显示了一个从该数据模型解释出来的对象模型。其中,嵌套接口定义了getSubProducts和setSubProducts方法。类NestedProduct扩展了基类Product并实现了嵌套接口。一条产品数据记录是属于Product还是属于NestedProduct依赖于它相应的产品发行记录的SubProductAllowable的值。
![]() 图1.产品和产品发行数据模型 ![]() 图2.产品和产品发行对象域模型 |
为了成功完成这个模型转化,我们使用了一个Hibernate3.x映射,如下:
<hibernate-mapping> <class name="Product" discriminator-value="0" lazy="false"> <id name="id" type="long"/> <discriminator formula="(select pr.SubProductAllowable from ProductRelease pr where pr.productReleaseID= productReleaseID)" type="integer" /> <subclass name="NestedProduct" discriminator-value="1"/> </class> </hibernate-mapping> |
如果规则表达式计算结果是0-也就是说,不允许有相应的子产品-那么该对象将是类Product。如果结果是1,该对象将是一个NestedProduct。在表1和表2中,对于Product表中的第一个记录(ProductID=10000001),初始化类将是一个NestedProduct,因为它通过SubProductAllowable=1参考引用一个ProductRelease记录。对于Product表中的第二个记录(ProductID=20000001),初始化类将是Product,因为它通过SubProductAllowable=0参考引用一个ProductRelease记录。
S/N | ProductReleaseID | SubProductAllowable | ... |
1 | 11 | 1 | ... |
2 | 601 | 0 | ... |
S/N | ProductID | ProductReleaseID | ... |
1 | 10000001 | 11 | ... |
2 | 20000001 | 601 | ... |