建站
咨詢
售后
建站咨詢
新聞中心
在前面簡(jiǎn)單描述了下服務(wù)層，SOA面向服務(wù)架構(gòu)，架構(gòu)設(shè)計(jì)-業(yè)務(wù)邏輯層，以及一些面向設(shè)計(jì)原則理解和軟件架構(gòu)設(shè)計(jì)箴言。這篇博客我們將繼續(xù)進(jìn)入我們的下一層：數(shù)據(jù)訪問(wèn)層。無(wú)論你用的是什么開發(fā)模式或者是業(yè)務(wù)模式，到最后最必須具有持久化機(jī)制，持久化到持久化介質(zhì)，并能對(duì)數(shù)據(jù)進(jìn)行讀取和寫入CRUD。這就是數(shù)據(jù)訪問(wèn)層。你可能是利用xml等文件格式磁盤存儲(chǔ)，常用的關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)，或者NoSql(not only sql)的內(nèi)存存儲(chǔ)或文檔存儲(chǔ)等等存儲(chǔ)介質(zhì)。而這里我只關(guān)心關(guān)系數(shù)據(jù)庫(kù)存儲(chǔ)。
數(shù)據(jù)層需要提供的職責(zé)有：
1：CRUD服務(wù)。作為唯一可以與存儲(chǔ)介質(zhì)交互的中間層出現(xiàn)，負(fù)責(zé)業(yè)務(wù)對(duì)象的增加，修改，刪除，加載。
2：查詢服務(wù)。這不同于CRUD中的R（read），read傾向于的單個(gè)對(duì)象，元組。而這里的查詢針對(duì)復(fù)雜查詢，比如一個(gè)國(guó)內(nèi)電商的客戶為四川的訂單。這里會(huì)涉及倉(cāng)儲(chǔ)層。所謂倉(cāng)儲(chǔ)模式指的是一個(gè)提供業(yè)務(wù)對(duì)象查詢的類，他隱藏了數(shù)據(jù)查詢的解析步驟，封裝sql解析邏輯。
3：事務(wù)管理。這里所說(shuō)的是業(yè)務(wù)事務(wù)，在一個(gè)應(yīng)用系統(tǒng)中每次請(qǐng)求都會(huì)產(chǎn)生多次的多數(shù)據(jù)對(duì)象的新增，修改，刪除操作。如果我們每次都依次代開數(shù)據(jù)庫(kù)連接，準(zhǔn)備數(shù)據(jù)包，操作數(shù)據(jù)庫(kù)，關(guān)閉數(shù)據(jù)連接。這些將會(huì)給我們帶來(lái)很多不必要的性能開銷。數(shù)據(jù)庫(kù)管理員經(jīng)常會(huì)要求“盡量少的與數(shù)據(jù)庫(kù)交互”，這也必須成為我們的開發(fā)原則。更好的操作是我們?cè)趦?nèi)存中建立一個(gè)和數(shù)據(jù)倉(cāng)庫(kù)，維護(hù)變化的對(duì)象，在業(yè)務(wù)操作完成一次性提交到數(shù)據(jù)存儲(chǔ)介質(zhì)，提供業(yè)務(wù)事務(wù)。業(yè)務(wù)事務(wù)有個(gè)很好聽的名字工作單元（UOW），在微軟給我們提供的DataSet，orm框架都回必須存在業(yè)務(wù)事務(wù)。
4：并發(fā)處理。UOW應(yīng)避免業(yè)務(wù)數(shù)據(jù)連接的多次提交打開而出現(xiàn)，但在內(nèi)存離線操作，這就可能導(dǎo)致數(shù)據(jù)一致性問(wèn)題。在多用戶的環(huán)境，對(duì)數(shù)據(jù)并發(fā)處理需要制定一個(gè)策略。一般我們會(huì)采用樂(lè)觀并發(fā)處理：用戶可以任意的離線修改，在修改更新時(shí)候檢查對(duì)象是否被修改，如果被修改者本次更新失敗。簡(jiǎn)單的說(shuō)就是防止丟失修改。防止丟失修改，我們可以采用where 加上一系列原值，或者加上修改時(shí)間戳或者版本號(hào)標(biāo)記。同時(shí)還有許多其他的并發(fā)解決模式，但樂(lè)觀并發(fā)鎖用到更普遍。
5：數(shù)據(jù)上下文：整和所有職責(zé)。在數(shù)據(jù)訪問(wèn)層概念職責(zé)都會(huì)有一個(gè)共同的暴露給外部的接口。我們需要一個(gè)高層次的組件，來(lái)同一提供對(duì)數(shù)據(jù)存儲(chǔ)介質(zhì)的訪問(wèn)操作。，同一訪問(wèn)數(shù)據(jù)庫(kù)CRUD，事務(wù)，并發(fā)服務(wù)的高層次類，叫做數(shù)據(jù)上下文（Context）。EF中的ObjectContext，NHibernate的session，linq to sql 的DataContext等等。
數(shù)據(jù)訪問(wèn)層的一些概念（這里不會(huì)是全部，僅一些個(gè)人覺(jué)得重要的概念）：
1： 數(shù)據(jù)映射器：將內(nèi)存中修改的對(duì)象提交至存儲(chǔ)介質(zhì)，則需要要映射邏輯來(lái)完成，數(shù)據(jù)映射器就是就是一個(gè)實(shí)現(xiàn)將某種類型的業(yè)務(wù)對(duì)象持久化的類（數(shù)據(jù)映射器模式定義如《P of EAA》）。
2：倉(cāng)儲(chǔ)層（Repository）：在上面提到：所謂倉(cāng)儲(chǔ)模式指的是一個(gè)提供業(yè)務(wù)對(duì)象查詢的類，他隱藏了數(shù)據(jù)查詢的解析步驟，封裝sql解析邏輯。在面向?qū)ο蟮氖澜缋镂覀冇脤?duì)象進(jìn)行查詢，返回結(jié)果為對(duì)象集。這里的查詢可能是從數(shù)據(jù)庫(kù)，或者來(lái)至緩存，這取決你的策略，你倉(cāng)儲(chǔ)層的實(shí)現(xiàn)。
3:工作單元（UOW）：Martin Fowler《P of EAA》 定義：工作單元記錄在業(yè)務(wù)事務(wù)過(guò)程中對(duì)數(shù)據(jù)庫(kù)有影響的所有變化。操作結(jié)束后，作為一種結(jié)果，工作單元了解所有需要對(duì)數(shù)據(jù)庫(kù)做的改變。在上面第3點(diǎn)業(yè)務(wù)事務(wù)講的差不多，這里不是累述。
4：標(biāo)示映射（Identity Map）：其作用在于：便于跟蹤業(yè)務(wù)對(duì)象，調(diào)用者在一個(gè)業(yè)務(wù)事務(wù)中使用的是同一個(gè)實(shí)例，而不是每次執(zhí)行產(chǎn)生一個(gè)新的對(duì)象。表示映射為一個(gè)散列表存儲(chǔ)（散列具有快速定位O(1)）。類似于緩存的實(shí)現(xiàn)方式，保證了在同一個(gè)業(yè)務(wù)事務(wù)數(shù)據(jù)上下文引用修改同一個(gè)業(yè)務(wù)對(duì)象。但絕不同于緩存。從持續(xù)時(shí)間來(lái)說(shuō)，標(biāo)示映射生命周期為業(yè)務(wù)事務(wù)內(nèi)。實(shí)現(xiàn)上等同于數(shù)據(jù)上下文期。但比起緩存來(lái)說(shuō)其周期太短，根本不能對(duì)性能有多大的改善。緩存更重要的命中率，而標(biāo)示映射保證同一數(shù)據(jù)上下文采用修改同一個(gè)業(yè)務(wù)對(duì)象的引用。
5：樂(lè)觀并發(fā)鎖：在上面也曾提到，其保證離線操作數(shù)據(jù)的對(duì)數(shù)據(jù)一致性的沖突解決方法。首先樂(lè)觀在于允許離線操作，容忍沖突，防止數(shù)據(jù)丟失修改，可利用原讀取數(shù)據(jù)值得where條件或者時(shí)間戳，版本號(hào)解決。
6：延時(shí)加載：對(duì)象并不是一次性加載完成，而是按照需求多次加載數(shù)據(jù)，到用時(shí)加載。業(yè)務(wù)對(duì)象太多關(guān)聯(lián)，數(shù)據(jù)量太多余龐大，而我們每次業(yè)務(wù)事務(wù)需要操作的對(duì)象都只會(huì)是部分，不需要太多的數(shù)據(jù)對(duì)象。同事業(yè)務(wù)對(duì)象中還存在循環(huán)引用，這樣不適于對(duì)象整體的一次性加載。延時(shí)加載提供了優(yōu)化，意圖在“盡可能的少加載，并按需加載，只加載需要的數(shù)據(jù)部分”。
7：持久化透明對(duì)象（PI或POCO）：當(dāng)對(duì)象模型不存在任何外部依賴，特別是對(duì)于數(shù)據(jù)訪問(wèn)層的依賴，那么這個(gè)模型就是持久化透明的，POCO。一個(gè)POCO的對(duì)象不需要繼承至某個(gè)特定的類，實(shí)現(xiàn)特定的接口，或提供專門的構(gòu)造函數(shù)。一個(gè)非持久化透明的對(duì)象這以為者存在外部的依賴，而我們更喜歡領(lǐng)域?qū)ο笾皇且粋€(gè)簡(jiǎn)單額c#類，可以在持久化層等獨(dú)立切換。這就導(dǎo)致實(shí)現(xiàn)的時(shí)候我們無(wú)法很直接的跟蹤業(yè)務(wù)對(duì)象，這就是面向方面編程（AOP）或者代理模式的大顯身手。可惜AOP在.net中不是那么直接，很多ORM框架如NHibernate之類的利用代理模式Emit動(dòng)態(tài)注入IL實(shí)現(xiàn)跟蹤，添加新的行為。所以NHibernate中要求領(lǐng)域?qū)ο蟮乃凶侄螌傩苑椒ǘ急仨毷翘摲椒芍貙懙摹?
8：CQRS（Command Query Responsibility Segregation，命令查詢職責(zé)分離）：CQRS是在DDD的實(shí)踐中引入CQS理論而出現(xiàn)的一種體系結(jié)構(gòu)模式，命令和查詢被分離。具體可以參 Martin Fowler的CQRS文章： http://martinfowler.com/bliki/CQRS.html
當(dāng)前文章：架構(gòu)設(shè)計(jì)：數(shù)據(jù)訪問(wèn)層簡(jiǎn)述
網(wǎng)頁(yè)地址：http://www.dlmjj.cn/article/dpocgsj.html
