在前面簡單描述了下
服務層，soa面向服務架構，架構設計-業務邏輯層，以及一些面面向設計原則理解和軟體架構設計箴言。這篇部落格我們將繼續進入我們的下一層：資料訪問層。無論你用的是什麼開發模式或者是業務模式，到最後最必須具有持久化機制，持久化到持久化介質，並能對資料進行讀取和寫入crud。這就是資料訪問層。你可能是利用xml等檔案格式磁碟儲存，常用的關聯式資料庫儲存，或者nosql(not only sql)的記憶體儲存或文件儲存等等儲存介質。而這裡我只關心關聯式資料庫儲存。
資料層需要提供的職責有：
1：crud服務。作為唯一可以與儲存介質互動的中間層出現，負責業務物件的增加，修改，刪除，載入。
2：查詢服務。這不同於crud中的r（read），read傾向於的單個物件，元組。而這裡的查詢針對複雜查詢，比如乙個國內電商的客戶為四川的訂單。這裡會涉及倉儲層。所謂倉儲模式指的是乙個提供業務物件查詢的類，他隱藏了資料查詢的解析步驟，封裝sql解析邏輯。
3：事務管理。這裡所說的是業務事務，在乙個應用系統中每次請求都會產生多次的多資料物件的新增，修改，刪除操作。如果我們每次都依次代開資料庫連線，準備資料報，運算元據庫，關閉資料連線。這些將會給我們帶來很多不必要的效能開銷。資料庫管理員經常會要求「盡量少的與資料庫互動」，這也必須成為我們的開發原則。更好的操作是我們在記憶體中建立乙個和資料倉儲，維護變化的物件，在業務操作完成一次性提交到資料儲存介質，提供業務事務。業務事務有個很好聽的名字工作單元（uow），在微軟給我們提供的dataset，orm框架都回必須存在業務事務。
4：併發處理。uow應避免業務資料連線的多次提交開啟而出現，但在記憶體離線操作，這就可能導致資料一致性問題。在多使用者的環境，對資料併發處理需要制定乙個策略。一般我們會採用樂觀併發處理：使用者可以任意的離線修改，在修改更新時候檢查物件是否被修改，如果被修改者本次更新失敗。簡單的說就是防止丟失修改。防止丟失修改，我們可以採用where 加上一系列原值，或者加上修改時間戳或者版本號標記。同時還有許多其他的併發解決模式，但樂觀併發鎖用到更普遍。
5：資料上下文：整和所有職責。在資料訪問層概念職責都會有乙個共同的暴露給外部的介面。我們需要乙個高層次的元件，來同一提供對資料儲存介質的訪問操作。，同一訪問資料庫crud，事務，併發服務的高層次類，叫做資料上下文（context）。ef中的objectcontext，nhibernate的session，linq to sql 的datacontext等等。
資料訪問層的一些概念（這裡不會是全部，僅一些個人覺得重要的概念）：
1： 資料對映器：將記憶體中修改的物件提交至儲存介質，則需要要對映邏輯來完成，資料對映器就是就是乙個實現將某種型別的業務物件持久化的類（資料對映器模式定義如《p of eaa》）。
2：倉儲層（repository）：在上面提到：所謂倉儲模式指的是乙個提供業務物件查詢的類，他隱藏了資料查詢的解析步驟，封裝sql解析邏輯。在物件導向的世界裡我們用物件進行查詢，返回結果為物件集。這裡的查詢可能是從資料庫，或者來至快取，這取決你的策略，你倉儲層的實現。
3:工作單元（uow）：martin fowler《p of eaa》 定義：工作單元記錄在業務事務過程中對資料庫有影響的所有變化。操作結束後，作為一種結果，工作單元了解所有需要對資料庫做的改變。在上面第3點業務事務講的差不多，這裡不是累述。
4：標示對映（identity map）：其作用在於：便於跟蹤業務物件，呼叫者在乙個業務事務中使用的是同乙個例項，而不是每次執行產生乙個新的物件。表示對映為乙個雜湊表儲存（雜湊具有快速定位o(1)）。類似於快取的實現方式，保證了在同乙個業務事務資料上下文引用修改同乙個業務物件。但絕不同於快取。從持續時間來說，標示對映生命週期為業務事務內。實現上等同於資料上下文期。但比起快取來說其週期太短，根本不能對效能有多大的改善。快取更重要的命中率，而標示對映保證同一資料上下文採用修改同乙個業務物件的引用。
5：樂觀併發鎖：在上面也曾提到，其保證離線運算元據的對資料一致性的衝突解決方法。首先樂觀在於允許離線操作，容忍衝突，防止資料丟失修改，可利用原讀取資料值得where條件或者時間戳，版本號解決。
6：延時載入：物件並不是一次性載入完成，而是按照需求多次載入資料，到用時載入。業務物件太多關聯，資料量太多餘龐大，而我們每次業務事務需要操作的物件都只會是部分，不需要太多的資料物件。同事業務物件中還存在迴圈引用，這樣不適於物件整體的一次性載入。延時載入提供了優化，意圖在「盡可能的少載入，並按需載入，只載入需要的資料部分」。
8：cqrs（command query responsibility segregation，命令查詢職責分離）：cqrs是在ddd的實踐中引入cqs理論而出現的一種體系結構模式，命令和查詢被分離。具體可以參 martin fowler的cqrs文章：
軟體架構設計系列總結 8 資料訪問層簡述
在前面簡單描述了下 服務層，soa面向服務架構，架構設計 業務邏輯層，以及一些面面向設計原則理解和軟體架構設計箴言。這篇部落格我們將繼續進入我們的下一層 資料訪問層。無論你用的是什麼開發模式或者是業務模式，到最後最必須具有持久化機制，持久化到持久化介質，並能對資料進行讀取和寫入crud。這就是資料訪...
軟體架構設計系列總結
出處 架構引用 維基百科 軟體體系結構是構建 計算機軟體 實踐的基礎。與建築師設定建築專案的設計原則和目標，作為繪圖員畫圖的基礎一樣，乙個 軟體架構師 或者系統架構師 陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。從和目的 主題 材料和結構的聯絡上來說，軟體架構可以和建築物的 架構相比...
軟體架構設計系列總結 9 儲存過程傳言
在google搜了下 儲存過程 優劣 關鍵字，資料並不多，出現了一篇關於來至51cto的關於儲存過程的優缺點的文章，具體這裡也不指出了。看見文章中對儲存過程的幾個辯解，個人不敢苟同，個人已經很仔細的看了文章的時間是2011年，如果在更前寫年成的話，個人覺得完全能夠理解。所以有了這篇，儲存過程的一些傳...