還是以前那句話，我不喜歡ORM這個(gè)詞，但是更多的時(shí)候又不得不用。

　　看到園友寫的“ ORM是進(jìn)化還是倒退？”的文章，禁不住想說上幾句。其實(shí)進(jìn)化(或者進(jìn)步?)或者倒退(或者退化?)是沒有一個(gè)清晰標(biāo)準(zhǔn)的，追求這個(gè)進(jìn)步或者倒退實(shí)在也沒有什么意義。但是這個(gè)標(biāo)題很惹人，很多年輕人很容易受到蠱惑，所以我必須站起來提醒一下他們。

　　ORM可以理解成object-relation-mapping，其實(shí)結(jié)構(gòu)就是api-database-model。很多人理解的ORM就是database→model→api。事實(shí)上這樣很自然，一直以來大家都是從數(shù)據(jù)庫(kù)設(shè)計(jì)開始一個(gè)系統(tǒng)的。所以各種基于數(shù)據(jù)庫(kù)的代碼生成器非常盛行，以至于linq2sql和ADOEF(或者有人叫l(wèi)inq2entity)也是數(shù)據(jù)庫(kù)先行。但是我之前所經(jīng)歷的ORM卻反而鮮見這種模式，所以我一直都沒有習(xí)慣過來。

　　最早接觸ORM這個(gè)詞，還是在1999~2001年前后混跡大富翁論壇的時(shí)候(那應(yīng)該也是大富翁論壇最鼎盛的時(shí)候)。有一群牛人把Java中的一些概念搬到Delphi上，的確讓人大開眼界。現(xiàn)在去看，還能看到過去的一些痕跡。沒有多久，Delphi上有了正式的ORM產(chǎn)品。首先出爐的是一個(gè)叫ModelMaker的MDA工具，有自己的Modeling GUI，從建模到api，渾然一體。MM以后，Bold for Delphi也慢慢火起來，這個(gè)基于UML的東東沒有自己的Modeling GUI，但是可以使用當(dāng)時(shí)流行的Rose或Together建模的成果。無論是MM還是BFD，都完全當(dāng)數(shù)據(jù)庫(kù)是一個(gè)透明的東西。這一類ORM模式是model→api→database，你幾乎沒有機(jī)會(huì)干預(yù)數(shù)據(jù)庫(kù)的定義、生成 和操作。我說這是“純”的orm。純倒是純了，徹底的OO了，但是你回頭看一下生成的數(shù)據(jù)庫(kù)，無字天書，比現(xiàn)如今sharepoint生成的數(shù)據(jù)庫(kù)還丑陋。遇到想做數(shù)據(jù)挖掘的用戶，只能是欲哭無淚了。在這方面，我承認(rèn)其后來者ECO有了明顯的改善，所以我一直相信ECO是一個(gè)偉大的產(chǎn)品，只是我用不起而已。

　　我認(rèn)識(shí)Hibernate是在2003年，后來我一直當(dāng)Hibernate是JDO的一個(gè)非EJB解決方案。Hibernate的確是按配置行事，先有數(shù)據(jù)庫(kù)，當(dāng)時(shí)仍然需要手工寫一堆entity代碼。一群懶人不屑做一些簡(jiǎn)單重復(fù)的事情，自動(dòng)生成這些配置文件，從此開了“代碼自動(dòng)生成”的先河。哈哈，如果你討厭“自動(dòng)代碼生成”，去找這些家伙們算賬吧，他們身在曹營(yíng)心在漢，搞Java的居然做這么m$的事情，受點(diǎn)委曲也是應(yīng)該的。所以，Hibernate是一個(gè)兼顧database的方案，也是database→model→api，盡管這個(gè)api其實(shí)是一堆配置。

　　你煩了當(dāng)數(shù)據(jù)庫(kù)變化以后，model和api的自動(dòng)同步，我可以接受。不過想一想呢，同步model和api總是有一些好的解決方案。如果你用面向過程的方式，model是沒有了，不需要同步了，但是那些api可都是一堆堆的sql語(yǔ)句，我不知道你可以用什么方式來同步。所以，無論OO也罷，PO以罷，進(jìn)化也好，退化也好，都不是你想討論的。你無非想要一個(gè)比較敏捷一點(diǎn)的方案罷了，如果你喜歡OO，當(dāng)然你會(huì)選擇ORM；反之，如果你喜歡PO，你也可以創(chuàng)造一個(gè)PRM(procedure-relation-mapping，我相信這個(gè)東東一定是可以做到的)。所以，不要告訴我什么OO與Database不匹配的話題，雖然我中意OO但我從來都認(rèn)為db4o不會(huì)成功。database和OO所解決的問題完全不在一個(gè)領(lǐng)域，兩者的功能是無法相互替代的。

　　我可是在.NET下用了N年的ORM，雖然跌跌撞撞也罷，至少我明白我要的是什么，而市面上的東西其中缺什么。對(duì)于我來說，好的ORM產(chǎn)品必須具備以下因素：

• 必須一切從模型開始，無論你是UML也罷，ER也罷，都可以。有Modeling GUI也好，沒有的話Hosting一個(gè)Addin到IDE也行。
• 必須有自動(dòng)代碼生成，并且既能生成api代碼，也能生成sql腳本。當(dāng)你的數(shù)據(jù)模型變化以后，改完model，你只需要按幾個(gè)鍵，然后所有的一切都有工具幫你搞定(當(dāng)然包括數(shù)據(jù)庫(kù)結(jié)構(gòu)重定義和測(cè)試數(shù)據(jù)自動(dòng)導(dǎo)入)。
• 功能上必須提供足夠的數(shù)據(jù)操作，性能可靠。必須支持引用、繼承和關(guān)聯(lián)三種關(guān)系，且繼承關(guān)系必須是一表一類。
• 除了能傳遞數(shù)據(jù)，還必須能夠傳遞“條件包”，當(dāng)然，運(yùn)行時(shí)的東東，可以是linq的expression也可以是hibernate的criteria。這是分層操作和分布式操作所必須的。
• 雖然通用的方式是以實(shí)體為類型、數(shù)據(jù)行為實(shí)例，也可以是以實(shí)體為組件(component)，而隱含行，但需要確保引用、繼承和關(guān)聯(lián)關(guān)系。

　　檢查一下ADOEF，頭一條就不符合，所以我只能放棄。ORM不會(huì)為我提供最好的性能、最好的設(shè)計(jì)，但是因?yàn)槠涿艚菪裕瑫?huì)為我提供最好的產(chǎn)能，特別是在業(yè)務(wù)復(fù)雜的時(shí)候。如果不是為了產(chǎn)能，ORM也沒有什么生命力。

　　別嚷嚷ORM不是萬(wàn)能的。誰(shuí)都沒有說過有什么東西是萬(wàn)能的。如果你都不訪問數(shù)據(jù)庫(kù)，你當(dāng)然不需要ORM了，所以不會(huì)有人說ORM是萬(wàn)能的。只有傻瓜才相信有人真的說過。

　　別嚷嚷OO不是萬(wàn)能的。誰(shuí)都沒有說過有什么東西是萬(wàn)能的。如果你都不需要處理復(fù)雜的關(guān)系，你當(dāng)然不需要OO了，所以不會(huì)有人說OO是萬(wàn)能的。只有傻瓜才相信有人真的說過。

it知識(shí)庫(kù)：ORM漫談，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。