ORM漫談

作者: 雙魚座  來源: 博客園  發布時間: 2008-12-14 20:39  閱讀: 3379 次  推薦: 0   原文鏈接   [收藏]  

  還是以前那句話,我不喜歡ORM這個詞,但是更多的時候又不得不用。

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

  ORM可以理解成object-relation-mapping,其實結構就是api-database-model。很多人理解的ORM就是database→model→api。事實上這樣很自然,一直以來大家都是從數據庫設計開始一個系統的。所以各種基于數據庫的代碼生成器非常盛行,以至于linq2sql和ADOEF(或者有人叫linq2entity)也是數據庫先行。但是我之前所經歷的ORM卻反而鮮見這種模式,所以我一直都沒有習慣過來。

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

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

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

  我可是在.net下用了N年的ORM,雖然跌跌撞撞也罷,至少我明白我要的是什么,而市面上的東西其中缺什么。對于我來說,好的ORM產品必須具備以下因素:

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

  檢查一下ADOEF,頭一條就不符合,所以我只能放棄。ORM不會為我提供最好的性能、最好的設計,但是因為其敏捷性,會為我提供最好的產能,特別是在業務復雜的時候。如果不是為了產能,ORM也沒有什么生命力。

  別嚷嚷ORM不是萬能的。誰都沒有說過有什么東西是萬能的。如果你都不訪問數據庫,你當然不需要ORM了,所以不會有人說ORM是萬能的。只有傻瓜才相信有人真的說過。

  別嚷嚷OO不是萬能的。誰都沒有說過有什么東西是萬能的。如果你都不需要處理復雜的關系,你當然不需要OO了,所以不會有人說OO是萬能的。只有傻瓜才相信有人真的說過。

0
0
 
標簽:ORM
 
 

文章列表

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 大師兄 的頭像
    大師兄

    IT工程師數位筆記本

    大師兄 發表在 痞客邦 留言(0) 人氣()