(一)對象之間的關系:
1.依賴:
依賴對象通過調用被依賴對象的方法來獲得服務。一種比較松散的關系,并且是短期的。我們的過程與對象往往依賴于我們的實體域對象。如在struts 的 action中調用模型層的方法。
2.關聯
它使一個類指到另一個類的屬性。長期的
3.聚合
聚合關系是關聯關系的一種,是強的關聯關系。聚合是整體和部分之間的關系。
4.組合
也叫合成關系,組成關系是關聯關系的一種,是比聚合關系強的關系。對象負責代表部分的對象的生命周期。
注:既然聚合,組合關系屬于關聯關系,那麼如何區分一般關聯關系,聚合關系群組合關系呢?
一般關聯:隻要一個對象聯系到另外一個對象就形成了關聯關系。如:人和他的貓,黑豹樂隊和窦魏,pc機和顯示器。
聚合關系:一種強關聯關系,它要求有部分和整體的關系,并且沒有了整體部分也可以獨立存在。在上面三個例子中人和它的貓顯然沒有部分和整體的關系,是以隻能是一般的關聯關系。而黑豹樂隊和窦魏,窦魏等人組成了黑豹樂隊即:窦魏和黑豹是整體和部分的關系。而窦魏脫離了黑豹(早就離開了)更或者黑豹不存在了那麼窦魏仍然可以以音樂人的身份存在(即對象仍然可以獨立存在)是以它屬于聚合關系。組成關系是可以共享的。(窦魏也可以加入其他樂隊)。
組合關系:一種更強的整體和部分的關系。它并且要求代表整體的對象負責代表部分的對象的生命周期,組成關系是不能共享的。如:pc機和顯示器的關系。
我覺得:如果兩個實體是整體和部分的關系,那麼它們到底是聚合還是組合,這取決于你的需求。比如說:pc機和顯示器的關系,如果你的系統中,顯示器脫離了pc機就不存在意義了,也可以說:所有顯示器的通路都是通過pc機進行的,那麼你可以把關系設定為組合(如你在為一個隻買品牌機的代理商作系統你可能是可以這麼作的)。如果你的顯示器脫離的pc機仍然可以獨立存在,也就是說在系統中可以直接通路顯示器對象,那麼你可以将關系設為聚合(如你在為一個買散件的代理商作系統你可能是可以這麼作的)
5.繼承
這個我不想多講了,用過面向對象的語言都應該知道。
(二)關系資料庫的關系
一對一
一對多
多對一
多對多
(三)o/r mapping政策
1.繼承:
對于繼承關系一般有三種政策:
政策1繼承樹的每個類對應一個表<joined-subclass >
共享主鍵
政策2繼承樹的根類對應一個表<discriminator ><subclass >
需要添加一個識别字段
政策3繼承樹的葉子類對應一個表
不支援多态查詢
2.關聯
2.1 一對一
一半有兩種政策:
政策1:唯一的外鍵
<many-to-one>+unique="true" (唯一的外鍵)
<one-to-one>
政策2:共享主鍵
<one-to-one><constrained="true"> (既是主鍵又是外鍵)
注意:生成方式需要用:foreign
2.2 一對多(無需多說)
2.3 多對一(無需多說)
2.4 多對多
政策1:A,B表多對多的關系需要引入C表。
C表中的所有屬性即為主鍵又為外鍵分别參照A,B兩表。
C表中不可以有其他屬性
政策2:将多對多拆分成兩個一對多:
A,B對象多對多的關系需要引入C對象。使得A,B兩對象與C對象的關系為一對多。對應資料庫中:A,B表多對多的關系需要引入C表。A,B兩表與C表的關系為一對多。
C表又自己的主鍵
C表中又非主鍵的外鍵分别參照A,B兩表。
如;學生 ,課程為多對多的關系 那麼引入學生選課。
注意:政策1和政策2的不同在于:政策2引入了新的對象而政策1沒有。這是因為這樣:政策1的c表不能又自己的東西。而政策2有。
2.5 其他
上面說過:聚合與組成是關聯的一種是以他們也符合以上政策。
特别的:當用到組合關系的是否我們可用用到hibernate的"元件"<component>.由于"元件"它完全可以滿足組成關系的強關聯。
3.依賴
一般不在實體域對象中展現。
O/R MAPPING (HIBERNATE)方法小結 (補充内容):
另外我看到了一種"鍵關聯"的方法,感覺很有道理。我了解了一下總結如下:
1.一般關聯:
這種方法對于一般的關聯總是引入c表(另外的一張表)僅僅表示關系。
C表的主鍵有分别指向A,B兩表(外鍵)。當指向一方的外鍵unique="true"即唯一,那麼這一方為"一",反之為"多"的一方。這樣就可以形成一般的關聯關系。但是注意的是:c表不映射為對象。C表也沒有自己的屬性。
2.聚合群組成
當實體A的非主鍵列中有一個引自實體B的時候,這種關系是B聚合A。如果這種引用是強制性的,則是合成關系,否則為聚合關系。是否為強制性,隻需要将引用列設為非空即可;
3.繼承
當實體A的主鍵引用自實體B的時候(即為外鍵),那麼A繼承 B。
總結:我覺得O/RM的方法有很多,我們可以看到"按外鍵"的方法思路很清晰。但是它在解決一般的關聯的時候總是引入另外一張表這樣勢必影響效率。另外,既然聚合群組合是關聯的一種那麼即使是組合關系我也把它看成一般關聯,也不算錯的。關系資料庫一開始就不是為了面向對象的語言服務的,是以我們在這裡映射無論那種方法似乎都不能說是完全的,正确無誤完成了O/RM。
是以我覺得一切都要看我們的項目需求。因地制宜!