在前面簡單描述了下服務層，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，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/86660.html
標籤：C++
上一篇：架構設計：業務邏輯層簡述