資料訪問層基礎結構設計

iDotNetSpace發表於2009-07-28
資料訪問層基礎結構設計目標：
1.完成物件導向的資料訪問
2.減少呼叫側程式碼量
3.滿足可擴充套件的系統需求
4.保證資料一致性

其中，對於訪問層基礎結構設計，採用如下原則。

1.對於物件導向系統，採用DataReader方式進行資料讀取；

2.為了減少呼叫側程式碼量和滿足可擴充套件的系統需求，採用反射實現動態的屬性訪問；
   作者參與系統使用Codeplex的專案FastReflection作為反射工具，對於物件基本屬性可通過屬性名字串直接訪問，
   例，Teacher類有屬性ClassID，我們可通過teacher.Item("ClassID")對其進行讀寫；
   很多人擔心反射的效率問題，當然自己每次生成屬性訪問器可達到只有4倍的效率低下，而直接使用FastReflection可能會達到近40倍的效率低下；但1000000次讀寫在0.7秒內完成與可擴充套件的目標權衡起來，還是可以採用的。

3.為了保證資料的一致性，我們採用每個資料表都有物理主鍵ID，型別為GUID的設計；同時使用DateTime型UpdDateTime欄位來記錄插入和更新時間，作為排他的基本條件。

   如何保證資料排他：
   使用者A和使用者B同時取得一條資料進行更新的同時，使用UpdDateTime作為條件，如果UpdDateTime一致則可進行更新；
   反之，無法進行更新。
   在編碼中，我們使用ExecuteNonQuery執行更新SQL文，而對返回的影響件數進行判斷；對於影響零件的情況，視為資料不一致的更新行為，報排他異常。

   對於主鍵的使用：
   小型系統一般都使用自動增長唯一標識列，都是提交資料後查詢主鍵，使用SQL Server 2005以上的系統，可以通過如下SQL文和輸出引數獲得自動增長的主鍵值：
   INSERT Categories(CategoryName) Values(@CategoryName) SET @Identity=SCOPE_IDENTITY()
   其中輸出引數@Identity就是返回的自動增長主鍵值。
   而對於比較複雜的系統，如包含部分更新及全部更新和主細表同時更新的情況下，需要自己在伺服器端進行主鍵設定，此種情況建議把主鍵型別設定為GUID型而不使用自動生成屬性，這樣就可以在更新執行之前設定主表資料主鍵以及詳細表資料的外來鍵並進行更新了。

4.事務控制方面，主要使用隱式事務在業務邏輯層就將事務開啟。

5.對於資料庫訪問層建議大家多使用Enterprise Libarary的資料訪問元件，優化方面可以根據自己的設計進行，同時可以使用AOP元件對結構進行優化，我們自己的專案使用PostSharp對所有層的異常處理和日誌輸出進行了優化。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12639172/viewspace-610607/，如需轉載，請註明出處，否則將追究法律責任。

相關文章