資料訪問層的設計我研究了很長時間，關於介面的定義，好幾次都推翻重來。
園子看到過很多easyui+mvc+ef的文章，在早期，我的設計也類似。
但是後來為了增強它，想加點功能通用的功能進去，就耗費了非常多的時間。
這是乙個怎麼樣的dal？
也許你已經見過許多實用ef的架構了，它是一套基於領域模型架構中的dal。
大致結構如圖中，dal就是最下面的那一層。
它的主要功能也體現在圖中了：增刪改服務、查詢、事務管理、併發，另外事務中包括工作單元，查詢中包括延遲載入。
我們希望底層的資料庫操作對其他層來說是透明的。
例如bll將感受不到orm工具的存在，他也不需要知道我們操作的資料庫是oracle，還是mssqlserver。
所以需要給dal抽象出乙個統一的介面，供其他層來操作，而底層我們可以分別使用各種orm工具，或者原生sql去實現。
看到圖中，會發現設計好dal統一的上下文是重點，因為它將會提供給其他層統一的介面，介面的定義是乙個難點。
乙個比較好的設計是底層實現依賴與高層抽象，而dal不能去依賴efdal/nhdal，這裡使用ioc工具就能輕鬆實現。
關於上下文的類圖：
idatacontext就是dal的上下文，而它需要被ef的上下文（context）/nh的上下文（session）分別實現，而原生的sql只能通過實現它的介面來構成所謂的上下文。
其中basedatacontext就是實現了一些通用的功能，比如事務管理、工作單元、唯一標識。
你會發現許多人都在bll直接使用orm的上下文，那是因為dal並沒有提供統一的上下文介面，只是提供了乙個統一的倉儲介面（irepository，比如iuserrepository）。
所以bll只能使用倉儲介面，而不能使用上下文中事務管理和工作單元，為了的條件查詢要麼讓倉儲提供更多的查詢方法，dal中orm特定的上下文貫穿所有層。
[test]id:11 name:yanpublic
void
querytest()
);//根據條件查詢
ilistusers= context.getbycriteria(query);
foreach (user user in
users)
\tname:
", user.id, user.name);
console.writeline(
"department:
",user.department.name);//
延遲載入
} }
department:mydept
id:10 name:13yan
department:mydept
上面的例子已經可以看到，統一的上下文能夠支援條件查詢和延遲載入。可以看出我使用的是那種orm嗎？
分頁
[test]id:1 name:lucypublic
void
pagelisttest()
\tname:
", user.id, user.name);
}console.writeline(
"sum:
",count);
}
id:3 name:lily
id:9 name:nddd
id:10 name:13yan
id:11 name:yan
id:41 name:adama3
sum:6
非工作單元
在非工作單元的事務中，add之後立即寫入了資料庫，可以看到user1已經寫入資料庫，並且持久化了。
工作單元
在工作單元的事務中，只要沒有commit()，新增物件的任務只是被暫存起來，到提交時一併執行。可以發現add之後並沒有寫入資料庫和持久化。
小結：中午時間真是短暫，時間關係就先寫到這裡吧，有興趣再接下去分析。
資料訪問層的設計（一） 功能與介面定義
資料訪問層的設計我研究了很長時間，關於介面的定義，好幾次都推翻重來。園子看到過很多easyui mvc ef的文章，在早期，我的設計也類似。但是後來為了增強它，想加點功能通用的功能進去，就耗費了非常多的時間。這是乙個怎麼樣的dal？也許你已經見過許多實用ef的架構了，它是一套基於領域模型架構中的da...
乙個資料訪問層的概要設計
以下是描述在乙個資料訪問層的設計過程 只乙個總體設計並不包含細節 運用基於介面程式設計的方法設計 以下純屬表達我個人的設計過程中方法，如果朋友有問題和見解發表出來多多交流。在做資料庫應用系統的過程經常要和資料處理物件，sql語句打交道 做久了就發覺其實這些工作可以通過封裝相應的元件來簡化這方面的工作...
乙個資料訪問層的概要設計
以下是描述在乙個資料訪問層的設計過程 只乙個總體設計並不包含細節 運用基於介面程式設計的方法設計 以下純屬表達我個人的設計過程中方法，如果朋友有問題和見解發表出來多多交流。在做資料庫應用系統的過程經常要和資料處理物件，sql語句打交道 做久了就發覺其實這些工作可以通過封裝相應的元件來簡化這方面的工作...