在領(lǐng)域模型中，類與類之間最普遍的關(guān)系就是關(guān)聯(lián)關(guān)系，以Customer和Order為例：

一個customer能發(fā)出多個訂單，而訂單只能是屬于一個用戶。那么從order到 customer的關(guān)聯(lián)關(guān)系是（N-1）的關(guān)聯(lián)。從customer到order一對多的關(guān)聯(lián)。

單向（N-1）關(guān)聯(lián)：

該類型的關(guān)聯(lián)只需要從N端到①端（也就是order到customer）。

域模型中：從order到customer的單向多對一關(guān)聯(lián)關(guān)系需要在order類中定義一個customer屬性，而在customer中無需定義存放order對象的集合屬性。

關(guān)系數(shù)據(jù)模型：ORDERS表中的CUSTOMER_ID參照CUSTOMERS表的主鍵：

步驟：

1.建立Customer類：

2.建立Order類：

3.利用hibernate插件生成hbm.xml文件，一般來說 該文件可能會根據(jù)實(shí)際情況作修改。

對于hbm.xml文件來說：

① ID生成策略一半選擇native。

②屬性對應(yīng)的數(shù)據(jù)字段名為帶下劃線的命名方式。

對于①端的配置由于是普通屬性，那么可以不做修改，對于N端配置，普通屬性也不用修改，但是在映射關(guān)聯(lián)關(guān)系屬性的時候需要注意：如下方式配置。

4.將hbm.xml文件添加到hibernate.cfg.xml文件的<mapping resource="路徑">下中。

5.運(yùn)行程序，由于在hibernate.cfg.xml文件中設(shè)置了自動生成數(shù)據(jù)表，那么程序運(yùn)行就會創(chuàng)建ORDERS／CUSTOMER兩張表。

下面我們分析測試類的運(yùn)行過程：

1.執(zhí)行save操作：

情況一：

先插入customer對象，再插入Order對象（也就是先插入①端的對象，再插入N端的對象，那么執(zhí)行3條insert語句）

情況二：

先插入Order對象，再插入Customer對象（先插入N端對象，再插入①端對象）

跟情況一相同，均可以執(zhí)行插入并成功。但是多出了兩條update語句。

為什么呢？

因?yàn)樵诓迦隣rder的時候，需要一個CUSTOMER_ID，但先執(zhí)行save操作的時候是立即發(fā)送的SQL，此時并不知道該外鍵，后續(xù)當(dāng)Customer插入之后，那么該外鍵在session中也就是存在的狀態(tài)了，程序繼續(xù)運(yùn)行到Transaction.commit（）的時候，會flush（），也就是提交前的沖刷過程，該過程會檢查session緩存中對象的初始狀態(tài)是否與現(xiàn)有狀態(tài)不一致，顯然在這里后來的customer對象的CUSTOMER_ID導(dǎo)致先前插入的Order對象發(fā)生變化，于是為了保持一致，執(zhí)行兩條update語句。

綜上兩種情況而言，由于我們對兩個關(guān)聯(lián)關(guān)系的對象save的順序不一樣，代碼的執(zhí)行過程也是不一樣的，顯然前者的效率較高。所以推薦使用先插入①端對象，再插入N端對象，以避免多余的update操作。

2.查詢操作：

在需要使用到關(guān)聯(lián)的對象的時候，才會發(fā)送對應(yīng)的SQL語句。

//若此時session.close()；那么會發(fā)生懶加載異常。

Customer ? ?customer = Order.getCustomer();

System.out.println(customer.getCustomerName());

其實(shí)在獲取Order的時候，默認(rèn)情況下，其關(guān)聯(lián)的Customer對象在沒有使用的時候是一個代理對象。

3.更新操作update

4.刪除操作：

在不設(shè)定級聯(lián)的情況下，且①端的對象有N端的對象在引用，那么便不能直接刪除①端的對象。