剖析 .Net 下的數據訪問層技術（五）
2024-07-10 13:03:38
供稿：網友
菜鳥學堂：
ø 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的基
礎上按需裁減，或者參考下面的“設計自己的持久層”中提出的方案。
