O/R Mapping 基本概念

文章目錄

• Feedback

(本文引自：http://www.cnblogs.com/idior/archive/2005/07/04/186086.html)
近日 有關o/r m的討論突然多了起來. 在這裡覺得有必要澄清一些概念, 免的大家討論來討論去, 才發現最根本的理解有問題.本文並不保證所有觀點正確, 只是個人在某一特定時期的理解.

1. 何謂Entity?
實體(類似於j2ee中的Entity Bean)通常指一個承載資料的對象, 但是注意它也是可以有行為的! 只不過它的行為一般只操作自身的資料. 比如下面這個例子:

class Person
{
  string firstName;
  string lastName;

  public void GetName()
  {
     return  lastName+firstName;
  }   
}

GetName就是它的一個行為.

2 何謂Domain Object?
對象最重要的特性在於它擁有行為. 僅僅擁有資料,你可以稱它為對象, 但是它卻失去它最重要的靈魂.

class Person
{
  string firstName;
  string lastName;
  Role role;
  int baseWage;
  public void GetSalary()
  {
     return baseWage*role.GetFactory();
  }   
}

這樣需要和別的對象(不是Value Object)打交道的對象,我就不再稱其為實體. 領域模型就是指由這些具有商務邏輯的對象構成的模型.

3. E/R M or O/R M?!!
仔細想想我們為什麼需要o/r m,無非是想利用oo的多態來處理複雜的商務邏輯, 而不是靠一堆的if else.
而現在在很多人的手上o/r m全變成了e/r m.他們不考慮對象的行為, 而全關注於如何儲存資料.這樣也難怪他們會產生將CRUD這些操作放入對象中的念頭. 如果你不能深刻理解oo, 那麼我不推薦你使用o/r m, Table Gateway, Row Gateway才是你想要的東西.

作為一個O/R M架構，很重要的一點就是實現映射的透明性（Transparent），比較顯著的特點就是在代碼中我們是看不到SQL語句的（架構自動產生了）,但是這並不是透明性的實質,詳見Enterprise Persistence Design,這裡所指的O/R M就是類似於此的架構.

4. POEAA中的相關概念
  很多次發現有人錯用其中的概念, 這裡順便總結一下:
  1. Table Gateway
    以表為單位的實體,基本沒有行為,只有CRUD操作.
  2. Row Gateway
    以行為單位的實體,基本沒有行為,只有CRUD操作.
  3. Active Record
    以行為單位的實體,擁有一些基本的操作自身資料的行為(如上例中的GetName),同時包含有CRUD操作.
其實Active Record最符合某些簡單的需求, 接近於E/R m.
通常也有很多人把它當作O/R m.不過需要注意的是Active Record中是充滿了SQL語句的(不像orm的SQL透明), 所以有人想起來利用O/R m來實現"Active Record", 雖然在他們眼裡看起來很方便, 其實根本就是返祖.
用CodeGenerator來實現Active Record也許是一個比較好的方法.
  4. Data Mapper
這才是真正的O/R m,Hibernate等等工具的目標.

5.O/R M需要關注的地方 (希望大家幫忙完善一下)
 1. 關聯以及與此相關的Lazy Load, O/R M是如何管理類之間的關聯.當然這不僅於O/R M有關與設計者的設計水平也有很大關係.
 2. O/R M對繼承關係的處理.
 3. O/R M對事務的支援.
 4. O/R M對查詢的支援.
 
以上觀點僅屬個人意見, 不過在大家討論有關O/R M之前, 希望先就一些基本概念達成共識, 不然討論下去會越離越遠.

(建議: 如果對oo以及dp沒有一定程度的瞭解, 最好別使用o/r m, dataset 加上codesmith或許是更好的選擇)

Feedback# re: O/R m 基本概念(歡迎指正)  回複   

2005-07-04 16:27 by Cavingdeep 不錯，理解到要點了！^_^# re: O/R m 基本概念(歡迎指正)  回複   

2005-07-04 16:31 by James good,講得很簡練而明白.# re: O/R m 基本概念(歡迎指正)  回複   

2005-07-04 16:47 by neuhawk 看了幾個.net開源的orm，總感覺不理想。
不是沒有發布穩定版本，就是有些功能太弱，如查詢、1:N、
N:M！# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-04 16:53 by 程式人生 探討！

我的觀點：
假設有鈔票，商店，一種設計是
鈔票.使用(商店);

一種是：
商店.銷售(鈔票)；

在這裡我認為鈔票是實體類，商店是操作類；
如果第一種設計在過了一個食堂的時候，那麼就勢必影響鈔票的行為：
鈔票.使用(食堂);

只有食堂和商店使用相同的介面，才能讓鈔票不必為後來的需求做修改，但這樣對以前的開發水準將有較高的要求。
如果使用後一種設計，那麼：
食堂.銷售飯(鈔票)；
這個後來的需求建立在已有的設計“鈔票”，所以不會影響以前的設計。# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-04 17:59 by tubo 其實前面已經說得很清楚了，鈔票自身還是可能有行為的（比如，兌換成美元），我想你不會去食堂兌換成美元吧# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-04 18:01 by cookey 程式人生 的探討話題和設計模式有關吧,好象和orm關係不大.# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-04 18:11 by 蛙蛙池塘 ORM的模型我就看過《asp.net電子商務進階編程》裡面用的那個CMP（託管容器持久性）的架構，是仿照J2EE來做的，大家有空也不妨研究一下，就有幾個類來做的，我感覺可用性還是可以的。也是每個持久對象可以執行CRUD，然後在資料服務層來封裝一下底層的商務邏輯# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-04 18:13 by idior 程式人生的問題涉及到責任分配的問題。

另外目前有兩種設計思路：
1。 將行為賦予包含待資料的對象本身
2。 XXX對象僅包涵資料， 通過另一個XXXmanager來操作該對象。
第二種在soa中比較常見， 不過以上都不是本文主要討論的問題， 希望大家的評論集中對orm的理解上上， 以上問題可以由誰再寫一篇文章討論。# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-05 09:27 by tdd No，不贊同。

Table Gateway、Row Gateway、Active Record、Data Mapper均是對象關係映射的實現模式，真正的對象關係映射目前是不存在的，所有的O/R Mapping方案都只不過是一個虛假的過渡品而已。嚴格來說，凡是能建立關係與對象之關的映射的，無論能力強弱，都可稱之為O/R Mapping方案.

所謂的Hibernate也只是眾多O/R Mapping解決方案相較更為廣泛使用的一種策略，它本身並不能說明什麼才是真的O/R。

# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-05 09:36 by 蛙蛙池塘 轉貼：【Uestc95的空間站 - 火星就是地球的未來?...
】http://blog.joycode.com/uestc95/archive/2003/11/04/5176.aspx

O/R Mapping，陷阱還是蘋果？
在JAVA的世界始終在討論的一個問題是：EJB是否欺騙了我們？當然這樣的問題就好像雞生蛋蛋生雞一樣沒有定論和結果，但是不容置疑的是EJB的確不是當初我們想像的那樣好，世界上本來就沒有救世主，一切還都要靠自己。而在.NET世界則更是如此，都說微軟提供了開發人員所需要的一切，從而使得開發人員越來越貶值，但實際情況卻恰恰相反，太多的東西他都沒有提供，比如O/R Mapping機制,持久維護機制等等。

使用MS提供的免費午餐帶來的代價就是：你別無選擇，因為你也根本沒有其他的選擇，比如COM+，Remoting，再比如以後的Indigo。從另外一個角度來講，這也未嘗不是一件好事情，當然前提你沒有發現JAVA世界的精彩。

上面的話其實沒有開始這篇隨筆的主題：O/R Mapping，陷阱還是蘋果？只是開始的一瞬間，思維胡亂跳躍。其實還有一個更大的延伸話題是：OO世界是否是一個虛幻的世界？當然這就不是我所能探討的話題了，你可以和OO大師們一論高低，

.NET 2.0將會提供O/R Mapping機制的實現，你自己看看就會發現他只是在和J2EE相靠攏,當然J2EE的O/R Mapping也是在向某種東西靠攏，究竟是什麼呢？你當然會說是：高效開發，提升可延展性，降低需求變化給軟體設計和編碼帶來的振蕩。沒錯，的確是這樣的。但是這樣作並不是沒有任何犧牲的，那就是增加編碼的複雜度和工作量，畢竟宇宙間能量是守恒的！ 是蘋果還是陷阱，就要看這些犧牲是否值得了。這就不是一個是或者否能精確回答的問題了，通過精確的項目控制和人為能力，完全可以做到高效率，而不採用O/R Mapping，比如前提是不考慮多資料庫支援。因為說到底，O/R Mapping機制提供的可延展性是非常有限的，他對於商務邏輯的支援基本上等於0，而我們大量的工作量都在商務邏輯部分。這也是我為什麼有這樣一個隨筆的原因所在。我們在仔細分析了當前業務環境之後就要決定O/R Mapping是否值得去使用，如果你追求的高效率，而不是所謂的“優美設計”，那麼就放棄吧。

比如我們高強度的ERP運算的時候，一定需要繞開O/R Mapping機制，否則等待我們的一定會是系統當機。而現在我發現越來越多的開發人員在刻意追求所謂的OO設計，尤其是.NET世界，雖然O/R Mapping算不上“過度設計”，但是本質一樣。所有提供O/R Mapping機制的技術都會提供對象緩衝技術，為什嗎？因為他知道這種構建實體和進行持久化的動作將會是非常耗費系統資源的，也就是說他們瞭解O/R Mapping所帶來的問題，通過對象緩衝技術來盡量抵消這個缺陷，但僅僅是“盡量”，所以我們開發或者分析設計人員更要明白的瞭解何時該繞過O/R Mapping!

不是說你運用OO技術和設計模式多麼熟練就表明你的功力有多高，而是說做到正確辨別何時該用什麼才是真正的高手。

# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-05 09:41 by 小殘 這篇轉貼講得好# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-05 09:51 by 雙魚座 哦，E/R Mapping是什麼東東？
不能接受這樣的評述：
仔細想想我們為什麼需要o/r m,無非是想利用oo的多態來處理複雜的商務邏輯, 而不是靠一堆的if else.
而現在在很多人的手上o/r m全變成了e/r m.他們不考慮對象的行為, 而全關注於如何儲存資料.這樣也難怪他們會產生將CRUD這些操作放入對象中的念頭. 如果你不能深刻理解oo, 那麼我不推薦你使用o/r m, Table Gateway, Row Gateway才是你想要的東西.

其實單純為了O/R Mapping而O/R Mapping毫無意義。在完整的開發週期中，前面需要領域模型(ER模型或者UML模型，兩者只是關注點不一樣)，後面有對業務層甚至表現層對O&R的消費。O/R Mapping有時候其實就是在物件導向與運行環境的中繼資料層的妥協而已。在某些特定情況下，對象這此僅僅只是一個資料容器並沒有異化物件導向的本質。
直接通過模型來產生領域對象代碼是為了提高開發的生產力。但是從模型中產生的程式碼往往都是“死對象”，都不包括行為。因為來自模型嘛。僅僅將這些對象作為資料容器或者關係容器也就足夠了。
實體的行為，可以通過另外的對象來補充之。事實上，在實際開發中，單純某個實體內部的行為少之又少，多態就更不需要了。

我對以上概念的理解：
對象：對於領域是抽象的，對於實體又是具體的概念
實體：一個中繼資料層級的概念，業務對象的描述器而已
關係：另外一個中繼資料層級的概念，彙總，合成，繼承，關聯，自引用，大概這麼五種吧。你所謂的Table Gateway, Row Gateway是無法描述複雜關係的。# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-05 09:57 by 雙魚座 >>不是說你運用OO技術和設計模式多麼熟練就表明你的功力有多高，而是說做到正確辨別何時該用什麼才是真正的高手。

經典！

# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-05 11:03 by 冰火 基本上贊同idior的理解。

但有兩點談談我的看法：
1、對ActiveRecord的理解不同意。
ActiveRecord本質上應該是領域模型，並不是實體+資料訪問。

ActiveRecord可以包含幾乎所有的領域邏輯，也可能只是一些面向資料的普通代碼。

ActiveRecord通常是和資料庫表同構的。一個包含了資料訪問的領域模型。因為他們是同構的，資料對應不太複雜，所以不必要用到分離的Mapper。

2、ORM需要關注的可能還有：標識，消極式載入，查詢。

個人觀點，歡迎討論！

# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-05 11:38 by Nineteen@newsmth "不是說你運用OO技術和設計模式多麼熟練就表明你的功力有多高，而是說做到正確辨別何時該用什麼才是真正的高手"----這句話真經典。很多人都變得為了技術而技術了，唉# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-05 12:36 by 寒楓天傷 不同意關於ActiveRecord的評述。

另外，多不多態，這是一個值得探討的問題，有一些大師級指出多態是一種沒事找事乾的行為，純屬瞎折騰（不過，我覺得還是很有用的）。另外還包括繼承之類的OO概念...也是非常值得爭議的。目前就OO而言，也不是很令人滿意，有理論背景因素，也有實踐因素，還有目前科學技術水平的制約。O/R目前實際上有空中樓閣之嫌，所有的東西都不如我們一開始認為的那樣好...還有待發展呐

# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-09 04:21 by workjie 不為了技術而技術，不這樣走過一段路，你能理解什嗎？
誰都是這樣過來的！# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-16 16:59 by happyprogram 學習。

workjie：關鍵是有沒有懸崖勒馬，呵呵

# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-07-18 16:51 by 菩提樹 發現各位口中的名詞真多,我基本上是應接不暇了
看來各位的概念是已經背的滾瓜爛熟了,慚愧,慚愧# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-08-10 22:58 by 生活、工作 Domain Object每個項目都是不同的，其所擁有的方法是由業務決定的，很難自動化。
現在都說三層，表現層、業務層、資料訪問層，這裡不說表現層。我這裡有三個類：OrderInfo、OrderDataServices、Order。其中，OrderInfo對應於這裡描述的Entity，這個是可以自動化的(比如用CodeSmith產生)，OrderDataServices在資料訪問層，執行CRUD和其他一些訪問資料庫的操作，我估計只能部分自動化，難以達到100%自動化，如果根據商務邏輯，先寫好部分預存程序，可能自動化程度會高一點(我這裡所說的並不是將商務邏輯寫進預存程序，而是將商務邏輯中最基礎的一些資料操作寫進預存程序)，Order在業務層，就更難自動化了，當然可以少部分自動化。
再舉個例子，UserInfo、UserDataServices、User，UserDataServices裡除了有CRUD操作外，還有個GetPassword()方法，這個顯然是根據商務邏輯而確定的，User類裡有個Authentication()方法，資料庫裡肯定沒有相關資訊，來給這個User類自動產生Authentication()方法。
ORM就字面來看，是說對象與對象之間的關係，好像與資料沒有很大聯絡，但我們在說ORM時卻往往根資料庫聯絡在一起，不知其最初是不是從資料而來的。
我水平有限，項目經驗也很少，不知說的對不對。# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-08-11 11:23 by idior @生活、工作
ORM是對象-關聯式資料庫映射的意思. 不是對象關係映射.
因為現在的編程模型多是oo模型,而資料庫用的又都是關係型資料庫, 所以才有了ORM的概念.# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-08-11 12:45 by 生活、工作 謝謝，知道了這裡的關係是指關聯式資料庫。

不過因為昨天有點事，我的回複還沒寫完，今天繼續。

如果僅根據資料庫，一般XXXXInfo、XXXXDataServices是可以產生的，但處於商務邏輯層的User類，還需要大量的商務資訊(如來源於UML的資訊)才能自動產生，那麼應該如何做呢？一般都是將商務邏輯層類所需要的方法放到設定檔裡，有ORM工具從設定檔中讀取商務資訊，從而產生商務邏輯層的類。這裡對象與對象之間的關係就體現在設定檔中。

我感覺如果僅僅產生類似XXXXInfo、XXXXDataServices類，用CodeSmith就不錯。如果也要產生Biz類，看來要用ORM工具了。

不知我的理解對不對，請指教。

# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-08-11 17:51 by idior @生活、工作
1。 o/r m不是代碼產生器。
2。 o/r m關注於持久層的操作， 商務邏輯與之無關。它不會自動產生業務代碼。
3。 o/r m的目的在於讓你關注商務邏輯的編寫，而較少的考慮資料儲存。

你的理解似乎有點偏差。

# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-08-11 22:18 by 生活、工作 呵呵，謝謝idior ，是我搞錯了，我的原本意思是這樣的：

如果僅根據資料庫，一般XXXXInfo是可以產生的，但處於資料訪問層的XXXXDataServices類只能部分產生，還需要大量的商務資訊(如來源於UML的資訊)才能自動產生，那麼應該如何做呢？一般都是將商務邏輯層類所要用到的、XXXXDataServices類的方法描述，放到設定檔裡，由ORM工具從設定檔中讀取這些資訊，從而產生資料訪問層的類。

請看看對不對？

# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-08-12 11:20 by idior XXXXDataServices中的方法基本上就是CRUD,似乎不需要描述, 設定檔中的資訊一般用於指導如何映射.
參考一下這個吧.
http://www.alphatom.com/content/view/267/69/# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-08-12 21:35 by 生活、工作 "XXXXDataServices中的方法基本上就是CRUD"，但我覺得還不夠，特別是R和U.# re: O/R Mapping 基本概念(歡迎指正)  回複   

2005-09-07 11:16 by yyanghhong 大多數系統有domain object, Data access object 和service layer就足夠了， 用hibernate可以實現domain object和Data access object, 它並沒有涉及service layer,
spring是把service和domain object, Data access object連在一起的好架構， 比如用他來配置service裡的transaction.

有人說DTO是用來實現傳遞資料在remote layer之間， 其實是多此一舉， hibernate裡可把domain object轉為detched object來達到這個目的， 用web service的話也可用xml attribute來serialize domain object. # re: O/R Mapping 基本概念(歡迎指正)  回複   

2006-02-01 20:53 by Niwalker ORM的思考：
大多人做OO總是喜歡鑽牛角尖，許多人認為關聯式資料庫的實體模型不是OO模型，這一點來說無疑是正確的，對於領域模型來說，域對象和資料庫中的實體物件不完全是一一對應的，於是有了各種各樣的映射模型出現。但是他們忽略了一個事實，那就是在OO世界中任何東西都可以表示為對象，資料庫也不例外，資料庫是對象，資料庫中的表同樣也是，況且很多業務更接近資料庫的關聯式模式，如日常中的報表之類（物件導向資料庫系統之所以不能廣泛流行的原因恐怕這也是其中之一吧？）。
當我們換一種角度來重新審視資料庫的時候，也就是說當你把資料庫看作一個對象的時候，那麼對象之間的關係是否會更清晰些？
日前看了DLinq(C#3.0)項目的實現，個人覺得MS的思路是正確的，這也是DLinq值得期待的一個理由。如果DLinq正是發布之時，我想上面的討論大多數都顯得很多餘。另外，注意一個事實，那就是DLinq並不只是ORM。# re: O/R Mapping 基本概念(歡迎指正)  回複   

2006-03-04 11:31 by ^_^ @Niwalker
使用ｏｒｍ就是一種把資料庫看成對象的方式吧。畢竟資料庫本身提供的介面不是物件導向的。ｏｒｍ就是一種跨系統邊界的封裝?