軟體架構設計系列總結 8 資料訪問層簡述

2021-06-10 10:28:48 字數 2218 閱讀 4637

在前面簡單描述了下

服務層,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年,如果在更前寫年成的話,個人覺得完全能夠理解。所以有了這篇,儲存過程的一些傳...