3.7.4 双向关联

 

到目前为止，一切看起来都工作的很好。但是我们仍然需要能够为特定的item取得所有的bid。这里我们需要一个双向的关联，因此我们需要为Item类添加一些代码：

你可以把addBid()方法当成是在对象模型中实现了一个可管理的关联。

一个基本的one-to-many关联看起来是这样：

<key>元素所定义的类映射是表格BID的一个外键列。注意在前的many-to-one关联映射中，我们也指定了同样的的列。在图3.11中你可以看到关于这个关联的表结构。

现在我们有了连个不同的单向映射关联到同一个外键，这可能会引发一个问题。在运行的时候，在内存中对于同一个外键的值有两个的表示：Bid的item属性和Item的bids集合。假设我们的应用程序通过addBid()方法为item增加了一个bid：

bid.setItem(item);

bids.add(bid);

看起来代码很简单，但是在这种情况下，对于同一个持久化实例，Hibernate会在内存中检测到两个不同的变化。从数据库的角度来看：仅仅需要一个值来反映这些变化：那就是修改ITEM_ID列。由于Hibernate无法检测到两个不同的变更实际上关联到同一个数据库列，因此我们需要指出这是一个双向关联才可以。

如果没有这个inverse属性，Hibernate会尝试执行两个不同的SQL语句，同时更新同一个外键列。通过inverse=”true”，我们可以明确的高速Hibernate关联的哪一端来同步数据库。在本例中，将由Bid来控制数据库的更新。因此，我们我们调用item.getBids().add(bid)方法的话，不会做任何的持久化。这与没有Hibernate的Java代码一样：如果关联是双向的，那么你需要在双方创建连接，而不是仅仅是单向的连接。

现在我们需要双向的many-to-one关联。

现在我们将来介绍cascading save和cascading delete，为此我们需要完成关于这个关联的映射。

当我们实例化一个Bid把它加到Item的时候，bid会马上进行持久化。我们需要避免显式的调用save()方法来完成持久化。

下面我们来配置映射使cascading save生效：

cascade属性告诉Hibernate如果一个Bid对象被一个持久化了的Item 应用的话，那么它也将被持久化。

cascade属性是是有方向性的：她只作用于关联的一端。我们也可以在many-to-one关联中指定cascade=”save-update”，但是这么做并不会起到任何作用，因为Bids是在Items之后创建的。

结束了？还没有完全结束。我们仍然需要定义关联中的实体的生命周期。