剖析.Net下的數(shù)據(jù)訪問層技術(shù)(5)

2019-11-18 12:06:45

字體：大中小

供稿：網(wǎng)友

　　Borland ECO
　　素以提供“多快好省”組件著稱的Borland公司在微軟發(fā)布ObjectSpaces之前率先推出了一套新的開發(fā)框架：ECO（EnterPRise Core Object），先不說其技術(shù)特點(diǎn)，就憑其與建模工具Together的無縫集成，不得不讓人佩服Borland在統(tǒng)一開發(fā)過程方面所下的功夫。
　　
　　根據(jù)Borland在ECO介紹中的定義，簡單說，ECO就是：模型驅(qū)動（MDA-Driven）的.Net數(shù)據(jù)庫應(yīng)用（Database application）開發(fā)框架（Framework）。
　　
　　（觀點(diǎn)：以作者看來，數(shù)據(jù)庫應(yīng)用的核心問題就是DAL，也就是本文需要討論的話題）
　　
　　很明顯，從MDA-Driven，Database Application和Frmework這些很具震撼效果的詞語不難看出，它們正是Borland公司以前及現(xiàn)在都無比強(qiáng)大的核心競爭力所在（當(dāng)然，還包括IDE、Components、Cross Platform等方面，一個公司能有這么多優(yōu)秀的產(chǎn)品，實在令人尊敬）！
　　
　　以前，在Borland平臺上開發(fā)數(shù)據(jù)庫應(yīng)用已經(jīng)非常方便，組件+可視化設(shè)計基本可以拿下比較簡單的應(yīng)用模塊。如今則更上一層，終于推出了自己的O/R Mapping解決方案！以作者的觀點(diǎn)，在Together這樣優(yōu)秀的Modeling工具加盟下，配合在Framework開發(fā)方面的數(shù)一數(shù)二實力（僅以藝術(shù)性而論，VCL Framework就可以拿該領(lǐng)域的奧斯卡獎），目前的ECO絕對穩(wěn)坐.NET O/R Mapping第一把交椅！
　　
　　（注重：ObjectSpaces尚未發(fā)布，暫不考慮。）
　　
　　關(guān)于ECO具體開發(fā)方面的介紹，大家可以參考“程序員，2003.12，P99”，“程序員，2004.01，P97”，“程序員，2004.02，P100”。
　　
　　以下，作者主要分析利用ECO開發(fā)所帶來的種種好處及其不足，供各位參考。
　　
　　優(yōu)點(diǎn)：
　　（1）　　與Typed DataSet（類型化的DataSet，在VS.NET中可自動生成）相比具有明顯優(yōu)勢；除了可以在UML/代碼間自由切換外，ECO可以支持自定義數(shù)據(jù)類型和計算類型（用過Delphi的朋友都知道這是個異常強(qiáng)大的武器）；
　　
　　（2）　　IDE提供強(qiáng)大的設(shè)計時支持，各種工具、組件一應(yīng)俱全，這也是Borland最擅長的領(lǐng)域；
　　
　　（3）　　集成Together建模工具，將MDA發(fā)揮得淋漓盡致；之所以將這條放在第3位，請參考下面的缺點(diǎn)分析；
　　
　　（4）　　引入Object Constraints Language（OCL），該標(biāo)準(zhǔn)得到了OMG組織的官方支持，號稱：OO SQL（面向?qū)ο蟮腟QL），對于不熟悉SQL的開發(fā)人員是一大福音；
　　
　　缺點(diǎn)：
　　（1）　　資源消耗較大，普通機(jī)器難以體會其優(yōu)勢；這方面，Rational XDE倒是做得相當(dāng)不錯；
　　
　　（2）　　有一定學(xué)習(xí)曲線，比如：OCL（Object Constraints Language），雖然與SQL不同，但從語法角度還不算十分簡潔；就作者自己的體會，可能學(xué)習(xí)XQuery（xml中的查詢語言）或OPath（ObjectSpaces中使用的查詢語言）要更輕松一些；
　　
　　（3）　　純商業(yè)產(chǎn)品，只有Architect版本才包含此功能，而ObjectSpaces直接包含在.NET Framework中，與VS.NET版本無關(guān)，可以通過.NET Framework SDK直接使用；
　　
　　（4）　　稍微過度MDA：DAL開發(fā)人員既然可以在ECO中生成數(shù)據(jù)庫腳本，那DBA是否也需要在ECO中進(jìn)行設(shè)計呢？
　　
　　對于企業(yè)級應(yīng)用，作者個人以為：MDA開發(fā)模式比較適用于DAL以上各層的開發(fā)，如：System Architecture，Business Façade，Business Logic，甚至User Interface，而對于Data Storage，可能并不是非常需要MDA介入。
　　
　　試想一下，O/R Mapping提供了映射關(guān)系，就是希望將RDBMS與其它層分離，假如現(xiàn)在全部在一個地方搞定，那豈不是又加重了開發(fā)人員的負(fù)擔(dān)（有時候自動化不見得越多越好）？
　　
　　還有一點(diǎn)：ECO宣稱“代碼/UML雙向同步”，但并沒有保證“代碼/字段可以不同”，這就在一定程度上喪失了靈活性！
　　
　　（提示：UML中“同步”意味著設(shè)計方案與代碼框架“一致”，但在O/R Mapping中，反而不要求這種“一致”，只需要在DAL與Schema間建立對應(yīng)關(guān)系既可，而Borland將傳統(tǒng)建模的思想照搬到DAL設(shè)計中，作者認(rèn)為是值得商榷的。這方面，其它的O/R Mapping方案就做得比較自然，突出了“Mapping”的含義，而不僅僅是簡單的“Synchronization”。）
　　
　　其它
　　還有一些其它的技術(shù)也可以實現(xiàn)O/R Mapping或類似功能，就作者試用過的一些解決方案來說，ConstrUCtor（國外）、Grove（國內(nèi)）都是不錯的選擇，Constructor甚至號稱“Model Driven RAD for .NET”，有愛好的朋友可以訪問如下站點(diǎn)：
　　
　　http://www.dotnetbuilders.com
　　
　　http://grove.911link.com
　　
　　說了許多，又到了“綜上所述”時間，作者再次放膽建議：
　　
　　（1）與基于ADO.NET的DAL實現(xiàn)方式不同，O/R Mapping有巨大優(yōu)勢，但也同時隱藏著風(fēng)險：最嚴(yán)重的問題就是與存儲過程的沖突！眾所周知，O/R Mapping的本質(zhì)是映射，在這方面各類實現(xiàn)都有其嚴(yán)格定義，說白了，就是將表操作轉(zhuǎn)化為對象操作。但存儲過程的靈活性（傳入?yún)?shù)，返回結(jié)果等）卻不得不使其暫時地被排除在O/R Mapping大家庭外（至少在目前，上述介紹過的OJB、ObjectSpaces等方案都不支持存儲過程）；另一方面，假如我們希望實現(xiàn)比較復(fù)雜的數(shù)據(jù)邏輯時，卻不得不以新的Object Language（如：OCL、OQL等）書寫原本可以封裝在存儲過程中的復(fù)雜SQL語句。而且，即使寫出了這些數(shù)據(jù)邏輯，也會令人感覺非常古怪甚至丑陋（某種意義上，這也違反了O/R Mapping的初衷）！第二個問題是：在O/R Mapping的環(huán)境中，系統(tǒng)的執(zhí)行效率將有一定損失，即使使用了Cache Management（一次性裝載配置文件）或者Delayed Loading（又稱Lazy Loading，只在訪問實體類數(shù)據(jù)時才真正連接數(shù)據(jù)庫）技術(shù)，由于在初次裝載數(shù)據(jù)時使用了Reflection機(jī)制去定位實體類（在某些方案中，映射關(guān)系以.NET Attribute方式體現(xiàn)，則更花時間），所以肯定不如直接通過ADO.NET填充數(shù)據(jù)來得那么快！假如各位認(rèn)為上述風(fēng)險不是問題，那下面的各條就是作者的真正建議了。
　　
　　（2）在大型應(yīng)用（一般指企業(yè)級應(yīng)用）開發(fā)中，ECO是很好的選擇；
　　
　　（3）假如是普通n-Tier應(yīng)用，則ObjectSpaces足矣；
　　
　　（4）想要學(xué)習(xí)O/R Mapping的朋友，可以看看OPF / OJB源碼，這兩個方案的實現(xiàn)思路與ECO / ObjectSpaces是有一些相似的；
　　
　　（5）假如不希望使用現(xiàn)成的O/R Mapping，則可在OPF / OJB的基礎(chǔ)上按需裁減，或者參考下面的“設(shè)計自己的持久層”中提出的方案。

上一篇：剖析.Net下的數(shù)據(jù)訪問層技術(shù)(6)

下一篇：剖析.Net下的數(shù)據(jù)訪問層技術(shù)(4)