O/R Mapping 的故事續集

記得在溫老先生的《程序設計心理學》裏,好像有對程序的功能和性能進行過深入的探討,比如一些藝術家級的程序員爲了實現一個性能完美的Hello World程序,花費了別人本來可以用來編寫一個應用服務器的時間。然而,當我們的程序規模大到一定程度,終究有一天要考慮性能問題。事實上在一些對性能要求高的應用程序中,在最初的設計中就必須爲性能埋下很好的伏筆。

人們對ASP.Net提出的質疑中,有這樣一種論調,就是現在的不少工具在爲程序員提供便利的同時,卻犧牲了最終用戶的使用體驗。事實上O/R Mapping也是類似,它能跨越兩種不同的編程模型,讓程序員用熟悉的OO編程方式來操作關係數據庫,卻讓數據在出入數據庫的時候,都必須通過一個包含着各種繁瑣耗時的動態映射的數據持久層。同樣也因爲使用了動態映射,在前文中XObject和XPath的取捨之間,如果加上性能的考慮,問題也會變得更加複雜。幸運的是,並非所有的場景都會對性能有如此高的要求,硬件的不斷髮展也成爲我們在性能設計上節省成本的很好藉口。然而數據庫的訪問,自古以來都是OLTP系統最常見的性能瓶頸。尤其對於那些需要同時支持上萬個終端的WEB應用,如何在功能、性能和開發效率之間取得平衡,的確是一個高深的工程難題。在這樣的應用中,如果廣泛使用O/R Mapping,可能就需要在硬件上投入更大的成本來彌補動態類型機制帶來的性能損失。我想一些後關係數據庫所標榜的性能優勢,可能大部分都應該得益於從存儲到編程都採用了統一的OO模型,而幾乎不需要在Mapping上花費太多代價。遺憾的是,在目前我們所處的環境裏,後關係數據庫還遠遠沒有成爲主流。

在後關係數據庫沒有來臨的日子裏,代碼自動生成的方案(比如CodeSmith+NTier)似乎也能很好地解決動態映射的問題。它把數據庫中的每個表映射成一個實體類(Entity)和一個控制類(Provider),字段就映射成實體類的屬性,增刪查改的動作就映射成控制類的方法。如果有自定義的存儲過程,你可以在控制類上增加一個方法進行封裝。實際上CodeSmith會幫你自動生成所有可以從數據庫直接映射過來的靜態代碼,相當於把傳統O/R Mapping提供的運行期動態機制重新移回編譯期,裏面還包含了衆多的設計模式和微軟社區裏面提供的Best Practise,最終組成一個比較完整的數據訪問層。除了CodeSmith以外目前還有不少代碼自動生成的工具,沒有時間去仔細研究,但CodeSmith提供的一種類似ASP.Net生成HTML的方式來生成代碼的方法,甚至還支持Code Behind,第一次看到的時候的確讓人眼前一亮。ASP.Net的確是個有趣的框架,哪怕是使用ASP.Net的宿主,通過它提供的那幾個基礎接口,可能也可以做出很多有趣的擴展。

除了性能之外,O/R Mapping的另外一個缺點就是不能動態改變數據庫結構。比如數據庫增加了一個字段,我們需要在類中增加一個成員的定義,或者讓CodeSmith重新生成一下代碼,然後重新編譯。爲了解決這個問題,一些中間件公司在它們的產品中就用XML來定義數據庫的Schema,然後整個從數據庫到數據訪問層到業務邏輯和界面表現都基於這個Schema來生成或者運作,它們的程序對任何的表、字段甚至類型都一視同仁,O/R Mapping提供的強類型對象在這種編程模型上也變得毫無意義了。於是我們就可以看到,如果要在客戶信息裏面增加一個Email字段,我們只需要做簡單的配置,然後從輸入客戶信息的Windows界面到WEB上的客戶一覽表都同時增加了一個EMAIL字段,同時更新的還有數據庫中的客戶信息表以及相關的存儲過程。

將這些動態機制用到及至,也許會徹底改變如今軟件行業的面貌。這在目前一些軟件裏面已經可以初見端倪,用戶甚至可以用一個嚮導來生成小型的MIS系統。將來更多的代碼將被自動生成,加上編譯器的輕量化,如今程序員所做的一部分低智能的工作將完全被機器取代,甚至還可能製造出能自己更新自己的應用程序。行業背景又不得不把我導向一個蹩腳的生物學比喻。現在的軟件系統更象是停留在低等的病毒時代,我們暫不討論它的感染和繁殖,它在體外就是一個僵硬的蛋白質外殼,壓根不象個生命體。未來的軟件應該進入細胞時代,有自己的核糖體,根據業務邏輯來製造它所需要的蛋白質,簡單地說就是把編譯器集成到常規的應用軟件中,讓它自己具有更新自己的能力。未來的未來,可能會經歷由單細胞變成多細胞,並衍生出幹細胞到各種功能特化細胞的過程。

其實我很不喜歡這些蹩腳的比喻,顯得如此幼稚而且外行看來簡直就是故弄玄虛。下面簡單地總結一下想象中下一代軟件系統的幾個基本組件,就算未來世界不一定是如此設計,但至少可以從一個技術側面反映了軟件行業的運作規則。現在其他三個基本組件都已經比較成熟了,最難的就是讓機器獲得需求(Generator)以生成可執行的程序代碼(Executer)的部分,也就是現在程序員的日常工作。

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章