剖析 .Net 下的資料訪問層技術(五)

來源:互聯網
上載者:User
訪問|資料 Ø Borland ECO

素以提供“多快好省”組件著稱的Borland公司在微軟發布ObjectSpaces之前率先推出了一套新的開發架構:ECO(Enterprise Core Object),先不說其技術特點,就憑其與建模工具Together的無縫整合,不得不讓人佩服Borland在統一開發過程方面所下的功夫。



根據Borland在ECO介紹中的定義,簡單說,ECO就是:模型驅動(MDA-Driven)的.Net資料庫應用(Database Application)開發架構(Framework)。

(觀點:以作者看來,資料庫應用的核心問題就是DAL,也就是本文需要討論的話題)



很明顯,從MDA-Driven,Database Application和Frmework這些很具震撼效果的詞語不難看出,它們正是Borland公司以前及現在都無比強大的核心競爭力所在(當然,還包括IDE、Components、Cross Platform等方面,一個公司能有這麼多優秀的產品,實在令人尊敬)!

以前,在Borland平台上開發資料庫應用已經非常方便,組件+可視化設計基本可以拿下比較簡單的應用模組。如今則更上一層,終於推出了自己的O/R Mapping解決方案!

以作者的觀點,在Together這樣優秀的Modeling工具加盟下,配合在Framework開發方面的數一數二實力(僅以藝術性而論,VCL Framework就可以拿該領域的奧斯卡獎),目前的ECO絕對穩坐.NET O/R Mapping第一把交椅!

(注意:ObjectSpaces尚未發布,暫不考慮。)



關於ECO具體開發方面的介紹,大家可以參考“程式員,2003.12,P99”,“程式員,2004.01,P97”,“程式員,2004.02,P100”。



以下,作者主要分析利用ECO開發所帶來的種種好處及其不足,供各位參考。



優點:

(1) 與Typed DataSet(類型化的DataSet,在VS.NET中可自動產生)相比具有明顯優勢;除了可以在UML/

代碼間自由切換外,ECO可以支援自訂資料類型

和計算類型(用過Delphi的朋友都知道這是個異常

強大的武器);



(2) IDE提供強大的設計時支援,各種工具、組件一應俱全,這也是Borland最擅長的領域;



(3) 整合Together建模工具,將MDA發揮得淋漓盡致;之所以將這條放在第3位,請參考下面的缺點分析;



(4) 引入Object Constraints Language(OCL),該標準得到了OMG組織的官方支援,號稱:OO SQL(物件導向的SQL),對於不熟悉SQL的開發人員是一大福音;



缺點:

(1) 資源消耗較大,普通機器難以體會其優勢;這方面,Rational XDE倒是做得相當不錯;



(2) 有一定學習曲線,比如:OCL(Object Constraints Language),雖然與SQL不同,但從文法角度還不算十分簡潔;就作者自己的體會,可能學習XQuery(XML中的查詢語言)或OPath(ObjectSpaces中使用的查詢語言)要更輕鬆一些;



(3) 純商業產品,只有Architect版本才包含此功能,而ObjectSpaces直接包含在.NET Framework中,與VS.NET版本無關,可以通過.NET Framework SDK直接使用;



(4) 輕微過度MDA:DAL開發人員既然可以在ECO中產生資料庫指令碼,那DBA是否也需要在ECO中進行設計呢?

對於企業級應用,作者個人以為:MDA開發模式比較適用於DAL以上各層的開發,如:System Architecture,Business Façade,Business Logic,甚至User Interface,而對於Data Storage,可能並不是非常需要MDA介入。

試想一下,O/R Mapping提供了映射關係,就是希望將RDBMS與其它層分離,如果現在全部在一個地方搞定,那豈不是又加重了開發人員的負擔(有時候自動化不見得越多越好)?

還有一點:ECO宣稱“代碼/UML雙向同步”,但並沒有保證“代碼/欄位可以不同”,這就在一定程度上喪失了靈活性!

(提示:UML中“同步”意味著設計方案與代碼架構“一致”,但在O/R Mapping中,反而不要求這種“一致”,只需要在DAL與Schema間建立對應關係既可,而Borland將傳統建模的思想照搬到DAL設計中,作者認為是值得商榷的。這方面,其它的O/R Mapping方案就做得比較自然,突出了“Mapping”的含義,而不僅僅是簡單的“Synchronization”。)



Ø 其它

還有一些其它的技術也可以實現O/R Mapping或類似功能,就作者試用過的一些解決方案來說,Constructor(國外)、Grove(國內)都是不錯的選擇,Constructor甚至號稱“Model Driven RAD for .NET”,有興趣的朋友可以訪問如下網站:

http://www.dotnetbuilders.com

http://grove.911link.com



說了許多,又到了“綜上所述”時間,作者再次放膽建議:

(1)與基於ADO.NET的DAL實現方式不同,O/R Mapping有巨大

優勢,但也同時隱藏著風險:



n 最嚴重的問題就是與預存程序的衝突!

眾所周知,O/R Mapping的本質是映射,在這方面各類實現

都有其嚴格定義,說白了,就是將表操作轉化為對象操作。

但預存程序的靈活性(傳入參數,返回結果等)卻不得不使

其暫時地被排除在O/R Mapping大家庭外(至少在目前,上

述介紹過的OJB、ObjectSpaces等方案都不支援預存程序);

另一方面,如果我們希望實現比較複雜的資料邏輯時,卻不

得不以新的Object Language(如:OCL、OQL等)書寫原

本可以封裝在預存程序中的複雜SQL語句。而且,即使寫

出了這些資料邏輯,也會令人感覺非常古怪甚至醜陋(某種

意義上,這也違背了O/R Mapping的初衷)!



n 第二個問題是:在O/R Mapping的環境中,系統的執行效率將有一定損失,即使使用了Cache Management(一次性裝載設定檔)或者Delayed Loading(又稱Lazy Loading,只在訪問實體類資料時才真正串連資料庫)技術,由於在初次裝載資料時使用了Reflection機制去定位實體類(在某些方案中,映射關係以.NET Attribute方式體現,則更花時間),所以肯定不如直接通過ADO.NET填充資料來得那麼快!



如果各位認為上述風險不是問題,那下面的各條就是作者的真正

建議了。



(2)在大型應用(一般指企業級應用)開發中,ECO是很好的

選擇;



(3)如果是普通n-Tier應用,則ObjectSpaces足矣;



(4)想要學習O/R Mapping的朋友,可以看看OPF / OJB源碼,

這兩個方案的實現思路與ECO / ObjectSpaces是有一些相似的;



(5)如果不希望使用現成的O/R Mapping,則可在OPF / OJB的基

礎上按需裁減,或者參考下面的“設計自己的持久層”中提出的方案。


相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。