熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java核心技術 >> 正文

剖析.Net下的數據訪問層技術(1)

2013-11-23 18:38:47  來源: Java核心技術 

  引言
  自從 NET 真正走入開發人員那天起效率兩個字就一直成為眾多程序員津津樂道的話題無論是從開發模式(Cross Language)系統框架(NET Framework)還是各種使用方便的工具(VSNET)無一不體現出了它的勝人一籌
  
  同時在另一方面NET 是否可以真正勝任企業級應用(Enterprise Application)開發的重任卻依然爭論不斷褒貶不一
  
  通常來說對於一個企業級應用需要考慮的方面很多如安全性能伸縮性易用性等在本文中作者更願意與大家一起探討 NET 下數據訪問層的相關技術這可能是在多層架構(nTier Architecture)誕生之日起就受到廣泛關注的敏感話題而對於大部分開發人員來說這也可能是項目中最讓人沮喪的部分甚或引起爭議最多的部分
  
  在以下論述中為統一起見作者暫時將數據訪問層簡稱為DAL(Data Access Layer)
  
  分析問題
  簡單統計分析後就不難發現DAL之所以讓人畏懼並非出於技術本身的問題甚至恰恰相反很多開發人員認為這是最沒有技術含量的部分之一(就作者經歷的大小項目來看該層所占的開發時間一般較短也是很多開發人員不願意承擔的苦差只是架構需要或者某些思想作怪(如為DAL而DAL)才加入了這所謂的第四層(傳統三層架構並沒有提出DAL思想)
  
  DAL的提出確實對傳統的架構模式提出了巨大挑戰加入的目的肯定也是希望借其進一步提高生產效率在這種模式下理想情況是大部分開發人員從此擺脫DBA之苦甚或徹底斷絕與數據庫的直接關系SQL之痛將離我們而去整個OO世界從此清靜
  
  不過理想歸理想能否成為現實則需通過項目檢驗
  
  接下來作者試圖分析比較流行且較有代表性的幾種解決方案看看能否從中得出一些有價值的結論並為我們今後在設計與實現DAL時提供一些借鑒
  
  ADONET
  首先提到NET下的DAL立刻映入眼簾的就是ADONET
  
  沒錯幾乎所有的DAL解決方案(請允許作者使用Solution而非Framework)都必須從它發展而來沒得選擇這也是具有NET特色的實現方式(相比較JEE)
  
  排除商業因素及CLR本身的需要ADONET真正帶給我們的東西不多值得一提的也就DataSet(就作者經歷的項目來說使用更多的是DataTable和DataView)從微軟早期的內存數據庫(Memory Database)鮮有人問津到今天的DataSet大行其道這其中的曲折實非片言只語所能道盡總之有一點可以肯定正是有了DataSet這種選擇NET下的DAL才能象今天這般百花齊放大家的思路才能更趨開闊
  
  Duwamish
  這方面有很多好的Sample最經典的莫過於微軟大力推薦的企業級開發套餐Duwamish對於希望學習NET下DAL設計的朋友這是一個不錯的起點這方面的完整剖析大家可以參考CSDN開發高手本文不再贅述
  
  作者自己參與的一個項目中就使用了Duwamish方案當時限於工期感覺這是一個很好的參考沒做深入分析就開始設計了現在回想起來發現還是有很多不足之處
  
  舉個簡單的例子Duwamish方案中並沒有考慮Cache Management而這對於企業級應用來說某些時候就是一個不得不考慮的問題另一方面雖然Duwamish中告別了SQL語句(全部采用存儲過程實現)但數據庫痕跡依舊十分明顯比如某些字段名稱的定義關聯表名稱的定義等等
  
  還有一個十分頭疼的問題是在開發過程中體現出來的一開始那些比較簡單的數據表還比較容易實現到了一些包含相互關系的數據表時我們的DAL工程師就感到了壓力到後來幾乎又做了一遍DBA在數據庫建模時早已做過的工作只不過這次將數據庫腳本換作了C# 實現(或者說將數據庫結構換成了表面上具有OO特色的DataSet)而已
  
  可能Duwamish的實現比較經典但在實際應用中有時並不意味著Best Practice就拿我們的項目來說雖然成功交付但無論從模型復用角度還是開發效率來說都不能算很成功套用一句流行語其實我們可以做得更好!
  
  PetShop
  ADONET上另一個值得參考的DAL實現就是鼎鼎大名的PetShop
  
  當然了與Duwamish相似名氣大未必真的實用PetShop雖然彌補了Duwamish在某些方面的不足例如通過Factory支持多種數據庫存儲引入了Cache機制提供了更為便利的SQL Helper但也同時帶來了另一些問題其中最麻煩的就是SQL語句的引入而且還是針對不同數據庫存儲的不同SQL語句(主要是SQL Server與Oracle的參數表示方式不同)
  
  另一方面PetShop雖然沒有使用DataSet而代之以更為簡潔的普通實體對象(Model)但它還是將DataReader的結果轉換到了包含實體對象的列表集合中供離線使用從這個意義上說可謂換湯不換藥甚至在某些場合例如需要進行數據過濾或者在主從數據間導航反而更為不便(此時簡單的Collection或者List是無法滿足需求的DBA與DAL開發人員只能再提供其它的方法來達到目的)
  
  從上述兩個例子中我們可以看出即使在微軟的開發團隊中也沒有能夠在DAL這個問題上達成一致這方面的更詳細信息有興趣的朋友可以參考如下文章
  
  
  
  實戰
  上面剖析的兩個解決方案讓我們看到了它們各自的優勢與不足而企業級應用的復雜環境也不太可能要求一個放之四海而皆准的框架就能解決所有難題因此只能根據具體情況具體分析作者曾經參與一個(NET)大型外包項目的開發工作有幸一睹其DAL的設計思想深感震撼在此與各位朋友一起共同探討以SQL Server所帶Northwind數據庫為例如下就是一段基於該DAL的調用代碼(作者做了一些名稱上的調整)
  
  // 根據EmployeeID返回其Title
  
  boEmp = new EmployeeDAL();
  
  boEmpKeys[Emp_ID] = ; // 注意實際字段名為EmployeeID
  
  boEmpSelect();
  
  string strTitle = boEmp[Emp_Title]; // 注意實際字段名為Title
  
  ……
  
  // 根據 City 返回所有符合條件的 Employee
  
  boEmp = new EmployeeDAL();
  
  boEmpKeys[Emp_City] = Seattle;
  
  boEmpSelect(); // 注意該方法與上面的調用完全相同
  
  DataTable dtEmp = boEmpTable;
  
  如果不考慮對象創建(可以采用Object Pooling或者Cached Object)以及調用後的處理實際的代碼只有兩行!
  
  更讓人吃驚的是上述EmployeeDAL類沒有任何真正意義上的實現代碼僅僅是聲明了類名然後從一個通用基類繼承而已!!
  
  最優雅的地方還不在於此實際上就算在那個基類中也根本看不到SqlConnection或者OracleAdapter之類的幫派之爭
  
  相信大家也猜出來了沒錯它是借鑒了PetShop的實現采用了Factory模式來保證DAL可以適用於不同的數據庫存儲不過這種實現與PetShop還是有很大的區別至少它沒有產生不同的SQL語句更沒有出現不同的參數調用方式(SQL Server中一般使用@符號Oracle中一般使用符號)所有幫派一視同仁!
  
  這其中當然得益於Factory的實現技巧但更重要的因素還在於設計方式的精妙其實NET Framework中已經提供了這種設計方式的基石說白了就是SystemData中的那些Interface(如IDBConnectionIdataAdapter等)
  
  在這樣的設計基礎上我們針對每一個DAL類就不再需要為不同的數據庫存儲提供不同的數據存取實現了例如在PetShop中針對訂單數據需要實現Order類很自然的系統為SQL Server與Oracle分別實現了Order類並使用不同Provider(SqlClientOracleClient)提供的方法進行操作而在實際調用時PetShop通過Factory模式動態創建真正的Order類並激活相應的方法一個面向不同數據庫存儲的方案就躍然紙上
  
  其實PetShop這種方案已經比較靈活了如果更能省去撰寫不同Order類之苦那就真的送佛送到天了J而所有這些功能在作者所參與的這個項目中已經完全搞定了!
  
  至於上面的EmployeeDAL(當然包括其它所有DAL類)沒有任何真正實現代碼只不過玩了一個小小的配置技巧而已將不同的DAL類與相關的Stored Procedure(請注意不是Table或View)按照Namespace分別存儲到XML文件中
  
  可能大家已經看出來了理論上甚至只需要一個DAL類就可以完成上述所有的工作!但在實際操作中不同的DAL類可能還是有一些數據處理上的細微差別(比如數據校驗格式轉換等)
  
  總的來說在這樣一個大項目中不可能要求所有開發人員(除了DBADAL Framework Developer)都去了解ADONET的方方面面雖然作者對此頗有研究但在這個項目中卻從頭至尾只用到了兩個類DataTableDataView(甚至連Transaction都無需了解)!
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25522.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.