架構設計：數據訪問層簡述

在前面簡單描述了下服務層，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：延時加載：對象並非一次性加載完成，而是按照需求屢次加載數據，到用時加載。業務對象太多關聯，數據量太多餘龐大，而咱們每次業務事務須要操做的對象都只會是部分，不須要太多的數據對象。同事業務對象中還存在循環引用，這樣不適於對象總體的一次性加載。延時加載提供了優化，意圖在「儘量的少加載，並按需加載，只加載須要的數據部分」。

7：持久化透明對象（PI或POCO）：當對象模型不存在任何外部依賴，特別是對於數據訪問層的依賴，那麼這個模型就是持久化透明的，POCO。一個POCO的對象不須要繼承至某個特定的類，實現特定的接口，或提供專門的構造函數。一個非持久化透明的對象這覺得者存在外部的依賴，而咱們更喜歡領域對象只是一個簡單額c#類，能夠在持久化層等獨立切換。這就致使實現的時候咱們沒法很直接的跟蹤業務對象，這就是面向方面編程（AOP）或者代理模式的大顯身手。惋惜AOP在.net中不是那麼直接，不少ORM框架如NHibernate之類的利用代理模式Emit動態注入IL實現跟蹤，添加新的行爲。因此NHibernate中要求領域對象的全部字段屬性方法都必須是虛方法可重寫的。:

8：CQRS（Command Query Responsibility Segregation，命令查詢職責分離）：CQRS是在DDD的實踐中引入CQS理論而出現的一種體系結構模式，命令和查詢被分離。

連接：https://pan.baidu.com/s/1v5gm7n0L7TGyejCmQrMh2g 提取碼：x2p5

免費分享，可是X度限制嚴重，如若連接失效點擊連接或搜索加羣 羣號744933466。