3.7.5 父子关联

 

在之前的映射中，在Bid和Item之间的关联是一种很松散的状态。在真实的环境中，如果关联的所有试题都有属于其自身的生命周期并且在不相关的业务操作中能被够被创建和删除的话，那么我们将会使用这种映射。特定的关联有着更强的约束；许多实体都是绑定在一起的遗嘱与它们的生命周期无法独立。在我们的例子中，对于item的删除也会将其拥有的所有bids删除。一个bid实例在其生命周期内只能关联到一个item实例。在这种情况下，cascading save和cascading delete都是有意义的。

如果我们是cascading delete生效的话，那么在Item和Bid之间的关联被称为父/子关联。在父/子关联中，父实体负责属于其的子实体的生命周期。这和组合有着相同的语义，但在这种情况下仅能包含实体；Bid并不是一种VO。利用父/子关联的好处是子实体能够独立的被装载或者能够被其他实体引用。一个bid实例，可以不用关联到item。在保存bid 的时候也不需要保存item实例。并且我们可以在另外一个Item实例中引用同一个Bid实例。而VO则不能共享。

为了重新构造Item和Bid之间的父/子关联，我们只需要改变cascade属性：

我们将casecade=”all-delete-orphan”，它具有如下意义：

如果Bid实例被一个持久化的Item引用的话，那么它将也会被持久化。同样，当Item实例被删除的时候，其关联的Bid实例也将被删除。

任何一个已经被持久化了的Bid实例，如果它从Item的集合中被删除的话，那么这个Bid实例也将被删除。

通过这个映射我们可以得出如下结论：一个Bid实例要么从其所在的集合中删除，或者从被应用的Item实例删除。

有关cascading的操作在Hibernate中被看作是transitive持久化的实现。我们在4.3中将更详细的讨论这个概念。

现在关于Hibernate中的关联我们仅仅是开了个头。然而，你已经拥有了足够的知识去开始你的程序了。剩下的配置方面的知识并不是经常使用。

我们强烈推荐尽量使你的映射保持简单，利用Hibernate查询来完成更复杂的任务。