别让Hibernate偷走了你的标识符
2008-01-05 09:03:04 来源:WEB开发网核心提示:摘要:当对象持久化到数据库中时,对象的标识符总时很难被恰当的实现,别让Hibernate偷走了你的标识符,尽管如此,问题其实完全是由存在着在保存之前不持有ID的对象的现象衍生而来的,我们并不想依靠于这两个方法的缺省实现,因为缺省实现并不能分辨代表数据库中同一实体的不同实例,我们可以通过从诸如Hibernate这样的对象
摘要:
当对象持久化到数据库中时,对象的标识符总时很难被恰当的实现。尽管如此,问题其实完全是由存在着在保存之前不持有ID的对象的现象衍生而来的。我们可以通过从诸如Hibernate这样的对象—关系映像框架手中取走指派对象ID的职责来解决这个问题。相对的,一旦对象被实例化,它就应该被指派一个ID。这使对象标识符变成简单而不易出错,也减少了领域模型中需要的代码量。
企业级java应用程序经常把数据在java对象和关系型数据库之间往返移动。从手动编写SQL代码到使用诸如hibernate这样的成熟的对象---关系映像(ORM)解决方案,有很多种方法可以实现这个过程。无论你采用什么样的技术,一旦你开始将java对象持久化到数据库中,对象标识符都将成为一个复杂而且难以治理的课题。可能出现的情况是:你实例化了两个不同的对象,而它们却代表了数据库中的同一行。为了解决这个问题,你可能采取的措施是在你的持久化对象中实现equals() 和hashCode()这两个方法,可是要恰当的实现这两个方法比乍看之下要有技巧一些。让问题更糟糕的是,那些传统的思路(包括hibernate官方文档所提倡的那些)对于新的工程并不一定能提出最实用的解决方案。
对象标识在虚拟机(VM)中和在数据库中的差异是问题滋生的温床。在虚拟机中,你并不会得到对象的id,你只是简单的持有对象的直接引用。而在幕后,虚拟机确实给每个对象指派了一个8字节大小的id,这个id才是对象的真实引用。当你将对象持久化到数据库中的时候,问题开始产生了。假定你创建了一个Person对象并将它存入数据库(我们可以叫它person1)。而你的其它某段代码从数据库中读取了这个Person对象的数据并将它实例化为另一个新的Person对象(我们可以叫它Person2)。现在你的内存中有了两个映像到数据库中同一行的对象。一个对象引用只能指向它们俩的其中一个,可是我们需要一种方法来表示这两个对象实际上表示着同一个实体。这就是(在虚拟机中)引入对象标识符的原因。
在java语言中,对象标识符是由每个对象都持有的equals()方法(以及相关的hashCode()方法)来定义的。无论两个对象(引用)是否为同一个实例,equals()方法都应该能够判别出它们是否表示同一个实体。hashCode()方法和equals()方法有关联是因为所有被判定等价(equal)的对象都应该返回相同的哈希值(hashCode)。在缺省实现中,equals()方法仅仅比较对象的引用,一个对象和它自身是等价的,而和其它任何实例都不等价。对于持久化对象来说,重写这两个方法,让代表着数据库中同一行的两个对象被判为等价是很重要的。而这对于java中的Collection数据结构(Set,Map和List)的正确工作更是尤为重要。
为了阐明实现equal()和hashCode()的不同途径,让我们一起考虑一个预备持久化到数据库中的简单对象Person。
public class Person {
PRivate Long id;
private Integer version;
public Long getId() { return id; }
public void setId(Long id) {
this.id = id;
}
public Integer getVersion() {
return version;
}
public void setVersion(Integer version) {
this.version = version;
}
// person-specific properties and behavior
}
在这个例子中,我们遵循了同时持有id字段和version字段的最佳实践。Id字段保存了在数据库中作为主键使用的值,而version字段则是一个从0开始增长的增量,随着对象的每次更新而变化(它帮助我们避免并发更新的问题)。为了看的更清楚,我们也一起看一下Hibernate把这个对象持久化到数据库的映像文件。
<?xml version="1.0"?>
<hibernate-mapping package="my.package">
<class name="Person" table="PERSON">
<id name="id" column="ID" unsaved-value="null">
<generator class="sequence">
<param name="sequence">PERSON_SEQ</param>
</generator>
</id>
<version name="version" column="VERSION" />
<!-- Map Person-specific properties here. -->
</class>
</hibernate-mapping>
Hibernate映像文件指明了Person的id字段代表了数据库中的ID列(也就是说,它是PERSON表的主键)。包含在id标签中的unsaved-value="null"属性告诉Hibernate使用id字段来判定一个Person对象之前是否被保存过。ORM框架必须依靠这个来判定保存一个对象的时候应该使用SQL的INSERT字句还是UPDATE字句。在这个例子中,Hibernate假定一个新对象的id字段一开始为null值,当它第一次被保存时才id才被赋予一个值。generator标签告诉Hibernate当对象第一次保存时,应该从哪里获得指派的id。在这个例子中,Hibernate使用数据库序列作为产生唯一id的来源。最后,version标签告诉Hibernate使用Person对象的version字段进行并发控制。Hibernate将会执行乐观锁方案(optimistic locking scheme),根据这个方案,Hibernate在保存对象之前会检查对比对象的version值和数据库中相应数据的version值。
我们的Person对象还缺少的是equals()方法和hashCode()方法的实现。既然这是一个持久化对象,我们并不想依靠于这两个方法的缺省实现,因为缺省实现并不能分辨代表数据库中同一实体的不同实例。一种简单而又显然的实现方法是利用id字段来进行equal()方法的比较以及生成hashCode()方法的结果。
当对象持久化到数据库中时,对象的标识符总时很难被恰当的实现。尽管如此,问题其实完全是由存在着在保存之前不持有ID的对象的现象衍生而来的。我们可以通过从诸如Hibernate这样的对象—关系映像框架手中取走指派对象ID的职责来解决这个问题。相对的,一旦对象被实例化,它就应该被指派一个ID。这使对象标识符变成简单而不易出错,也减少了领域模型中需要的代码量。
企业级java应用程序经常把数据在java对象和关系型数据库之间往返移动。从手动编写SQL代码到使用诸如hibernate这样的成熟的对象---关系映像(ORM)解决方案,有很多种方法可以实现这个过程。无论你采用什么样的技术,一旦你开始将java对象持久化到数据库中,对象标识符都将成为一个复杂而且难以治理的课题。可能出现的情况是:你实例化了两个不同的对象,而它们却代表了数据库中的同一行。为了解决这个问题,你可能采取的措施是在你的持久化对象中实现equals() 和hashCode()这两个方法,可是要恰当的实现这两个方法比乍看之下要有技巧一些。让问题更糟糕的是,那些传统的思路(包括hibernate官方文档所提倡的那些)对于新的工程并不一定能提出最实用的解决方案。
对象标识在虚拟机(VM)中和在数据库中的差异是问题滋生的温床。在虚拟机中,你并不会得到对象的id,你只是简单的持有对象的直接引用。而在幕后,虚拟机确实给每个对象指派了一个8字节大小的id,这个id才是对象的真实引用。当你将对象持久化到数据库中的时候,问题开始产生了。假定你创建了一个Person对象并将它存入数据库(我们可以叫它person1)。而你的其它某段代码从数据库中读取了这个Person对象的数据并将它实例化为另一个新的Person对象(我们可以叫它Person2)。现在你的内存中有了两个映像到数据库中同一行的对象。一个对象引用只能指向它们俩的其中一个,可是我们需要一种方法来表示这两个对象实际上表示着同一个实体。这就是(在虚拟机中)引入对象标识符的原因。
在java语言中,对象标识符是由每个对象都持有的equals()方法(以及相关的hashCode()方法)来定义的。无论两个对象(引用)是否为同一个实例,equals()方法都应该能够判别出它们是否表示同一个实体。hashCode()方法和equals()方法有关联是因为所有被判定等价(equal)的对象都应该返回相同的哈希值(hashCode)。在缺省实现中,equals()方法仅仅比较对象的引用,一个对象和它自身是等价的,而和其它任何实例都不等价。对于持久化对象来说,重写这两个方法,让代表着数据库中同一行的两个对象被判为等价是很重要的。而这对于java中的Collection数据结构(Set,Map和List)的正确工作更是尤为重要。
为了阐明实现equal()和hashCode()的不同途径,让我们一起考虑一个预备持久化到数据库中的简单对象Person。
public class Person {
PRivate Long id;
private Integer version;
public Long getId() { return id; }
public void setId(Long id) {
this.id = id;
}
public Integer getVersion() {
return version;
}
public void setVersion(Integer version) {
this.version = version;
}
// person-specific properties and behavior
}
在这个例子中,我们遵循了同时持有id字段和version字段的最佳实践。Id字段保存了在数据库中作为主键使用的值,而version字段则是一个从0开始增长的增量,随着对象的每次更新而变化(它帮助我们避免并发更新的问题)。为了看的更清楚,我们也一起看一下Hibernate把这个对象持久化到数据库的映像文件。
<?xml version="1.0"?>
<hibernate-mapping package="my.package">
<class name="Person" table="PERSON">
<id name="id" column="ID" unsaved-value="null">
<generator class="sequence">
<param name="sequence">PERSON_SEQ</param>
</generator>
</id>
<version name="version" column="VERSION" />
<!-- Map Person-specific properties here. -->
</class>
</hibernate-mapping>
Hibernate映像文件指明了Person的id字段代表了数据库中的ID列(也就是说,它是PERSON表的主键)。包含在id标签中的unsaved-value="null"属性告诉Hibernate使用id字段来判定一个Person对象之前是否被保存过。ORM框架必须依靠这个来判定保存一个对象的时候应该使用SQL的INSERT字句还是UPDATE字句。在这个例子中,Hibernate假定一个新对象的id字段一开始为null值,当它第一次被保存时才id才被赋予一个值。generator标签告诉Hibernate当对象第一次保存时,应该从哪里获得指派的id。在这个例子中,Hibernate使用数据库序列作为产生唯一id的来源。最后,version标签告诉Hibernate使用Person对象的version字段进行并发控制。Hibernate将会执行乐观锁方案(optimistic locking scheme),根据这个方案,Hibernate在保存对象之前会检查对比对象的version值和数据库中相应数据的version值。
我们的Person对象还缺少的是equals()方法和hashCode()方法的实现。既然这是一个持久化对象,我们并不想依靠于这两个方法的缺省实现,因为缺省实现并不能分辨代表数据库中同一实体的不同实例。一种简单而又显然的实现方法是利用id字段来进行equal()方法的比较以及生成hashCode()方法的结果。
- ››Hibernate高级应用:性能优化策略
- ››hibernate 多对多关系详解(包括中间表,一对多字表...
- ››Hibernate实现mysql数据库limit查询方法
- ››Hibernate 之父:是时候升级到Java EE 6了
- ››Hibernate查询
- ››Hibernate和iBATIS比较(摘自网络)
- ››Hibernate使用Projections进行聚合操作
- ››hibernate中java.util.Date类型映射
- ››hibernate中update与saveOrUpdate的区别
- ››Hibernate各种映射关系总结
- ››Hibernate过滤器使用窍门
- ››Hibernate属性查询简单讲述
更多精彩
赞助商链接