一,、上章回顧

       上章我們主要講述了系統(tǒng)設(shè)計(jì)規(guī)范與原則中的具體原則與規(guī)范及如何實(shí)現(xiàn)滿足規(guī)范的設(shè)計(jì),，我們也講述了通過(guò)分離功能點(diǎn)的方式來(lái)實(shí)現(xiàn)，而在軟件開(kāi)發(fā)過(guò)程中的具

體實(shí)現(xiàn)方式簡(jiǎn)單的分為面向過(guò)程與面向?qū)ο蟮拈_(kāi)發(fā)方式,，而目前更多的是面向?qū)ο蟮拈_(kāi)發(fā)設(shè)計(jì)方式,。并且我們也講述了該如何通過(guò)設(shè)計(jì)手段去分析功能點(diǎn)及設(shè)計(jì)分離

點(diǎn)，應(yīng)該如何在設(shè)計(jì)的過(guò)程中分析的角度及如何去滿足設(shè)計(jì)規(guī)范與原則,。首先我們通過(guò)下圖來(lái)回顧下上章要點(diǎn)：

二,、摘要

        本文將已架構(gòu)的方式去分析分層結(jié)構(gòu)中的業(yè)務(wù)層的設(shè)計(jì)，如何寫(xiě)出來(lái)內(nèi)聚度,，高耦合的業(yè)務(wù)邏輯層,，并且如何根據(jù)我們的項(xiàng)目中的個(gè)功能需要去設(shè)計(jì)業(yè)務(wù)層。我

們本章將會(huì)通過(guò)幾種可能的業(yè)務(wù)層的設(shè)計(jì)模式去分析,，并且分析每種設(shè)計(jì)模式的優(yōu)點(diǎn)與缺點(diǎn)及每種設(shè)計(jì)模式的應(yīng)用場(chǎng)景,并且結(jié)合一定的使用實(shí)例來(lái)講解,，當(dāng)然這些具體

的內(nèi)容都是自己在項(xiàng)目中的經(jīng)驗(yàn)與總結(jié)。錯(cuò)誤之處,，在所難免,，本人抱著求真務(wù)實(shí)的態(tài)度，爭(zhēng)取寫(xiě)好每一篇文章,，錯(cuò)誤之處還請(qǐng)大家匹配之處,，如果您有好的意見(jiàn)或建

議，可以及時(shí)跟我溝通,，如果對(duì)系統(tǒng)架構(gòu)中的設(shè)計(jì)規(guī)范與模式不了解,，可以點(diǎn)擊這里查看上篇文章：系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)設(shè)計(jì)規(guī)范與原則[下篇]

        本章講解的內(nèi)容我們先看下圖中的幾個(gè)簡(jiǎn)單模式：

三,、本章大綱

       1、上章回顧,。

       2,、摘要。

       3,、本章大綱,。

       4、業(yè)務(wù)層設(shè)計(jì)分析,。

       5,、幾種不同的業(yè)務(wù)設(shè)計(jì)模式。

       6,、本章總結(jié),。

       7、系列進(jìn)度,。

       8,、下篇預(yù)告。

四,、業(yè)務(wù)層設(shè)計(jì)分析

        本節(jié)中將會(huì)對(duì)業(yè)務(wù)層的設(shè)計(jì)進(jìn)行詳細(xì)的分析,。

        首先、我們知道業(yè)務(wù)層是一個(gè)系統(tǒng)中最核心的部分,，業(yè)務(wù)層是實(shí)現(xiàn)系統(tǒng)業(yè)務(wù)功能的核心邏輯層,。業(yè)務(wù)層我們通常說(shuō)的BLL(Business Logic Layer)層，現(xiàn)在我們

一般的稍微復(fù)雜一些的業(yè)務(wù)邏輯都是通過(guò)分層結(jié)構(gòu)來(lái)構(gòu)建一個(gè)應(yīng)用系統(tǒng),，我想大家在組織業(yè)務(wù)邏輯功能時(shí)大部分的情況下是使用BLL層單獨(dú)負(fù)責(zé)相應(yīng)的業(yè)務(wù)邏輯來(lái)實(shí)現(xiàn)

的,。有些應(yīng)用可能業(yè)務(wù)邏輯層并不復(fù)雜，這是我們可以把問(wèn)題簡(jiǎn)單化,，不用引入一些框架性的東西來(lái)提升系統(tǒng)的復(fù)雜度,，但是有些業(yè)務(wù)規(guī)模較大，并且業(yè)務(wù)邏輯性較強(qiáng)

時(shí),，可能使用好的業(yè)務(wù)設(shè)計(jì)模式帶來(lái)的優(yōu)越性就顯而易見(jiàn)了,。 我們大家都知道業(yè)務(wù)邏輯層主要是用來(lái)處理領(lǐng)域模型對(duì)象之間的邏輯關(guān)系的部分。我們都知道業(yè)務(wù)層的數(shù)

據(jù)最終是要保存到數(shù)據(jù)庫(kù)中,，我們?cè)谶M(jìn)行業(yè)務(wù)層設(shè)計(jì)時(shí)一般是在架構(gòu)中的分層架構(gòu)模式中出現(xiàn)的,。我們知道分層結(jié)構(gòu)中一般是將領(lǐng)域模型與底層數(shù)據(jù)訪問(wèn)、表現(xiàn)層等進(jìn)

行分開(kāi)組織,，這樣可以讓系統(tǒng)結(jié)構(gòu)上清晰,，并且容易降低他們之間的耦合性。

        其次,、其實(shí)我們的很多操作都是可以在業(yè)務(wù)層來(lái)完成,，比如說(shuō)用戶的角色權(quán)限,，數(shù)據(jù)驗(yàn)證等一些基本的業(yè)務(wù)規(guī)則。當(dāng)然這里說(shuō)明業(yè)務(wù)層主要負(fù)責(zé)系統(tǒng)中的業(yè)務(wù)規(guī)

則的實(shí)現(xiàn),。這里我們需要知道2個(gè)概念,，就是對(duì)象模型與領(lǐng)域模型：下面我們說(shuō)下這2者的區(qū)別。

        描述對(duì)象模型與領(lǐng)域模型的區(qū)別,。

        最后,、業(yè)務(wù)邏輯層作為分層系統(tǒng)中的中間位置，業(yè)務(wù)模型是表現(xiàn)層與數(shù)據(jù)層之間的紐帶,。當(dāng)然一般我們?cè)谙到y(tǒng)設(shè)計(jì)時(shí),，可能我們一般不會(huì)把領(lǐng)域模型中的領(lǐng)域?qū)?/p>

體作為分層之間的傳輸信息，因?yàn)橐话銇?lái)說(shuō)領(lǐng)域模型中的實(shí)體不但包含實(shí)體的數(shù)據(jù)信息,，并且包含實(shí)體的行為,。可能我們?cè)诟鲗又兄粫?huì)用到實(shí)體的數(shù)據(jù)信息,，那么無(wú)疑

這時(shí)采用領(lǐng)域?qū)嶓w的形式進(jìn)行傳輸,，那么會(huì)增加系統(tǒng)的傳輸負(fù)載。當(dāng)然這里就會(huì)出現(xiàn)我們平時(shí)所謂的3層模式中的Model層,。當(dāng)然Model層設(shè)計(jì)的主要作用就是實(shí)體數(shù)據(jù)

的承載,，其中并不包含任何行為。具體的行為通過(guò)數(shù)據(jù)訪問(wèn)層來(lái)實(shí)現(xiàn)CRUD（DDL中的四個(gè)基本操作）的操作,。

        目前我們?cè)O(shè)計(jì)的分層結(jié)構(gòu)中的對(duì)象模型中并不包含實(shí)體的行為。其實(shí)這里可以看作是比

較好的設(shè)計(jì)方式,，因?yàn)椴捎脤?duì)象模型的方式進(jìn)行數(shù)據(jù)傳輸時(shí)可以降低系統(tǒng)的耦合,。當(dāng)然我們也可以把領(lǐng)域?qū)嶓w看作是多個(gè)對(duì)象實(shí)體的組合并且包含這些對(duì)象實(shí)體之間的

關(guān)系。所以我們?cè)谧鱿到y(tǒng)架構(gòu)時(shí)可能如何權(quán)衡就比較重要,，具體是使用領(lǐng)域?qū)嶓w進(jìn)行數(shù)據(jù)傳輸還是對(duì)象實(shí)體主要還是看業(yè)務(wù)的需要,。

五、幾種不同的業(yè)務(wù)設(shè)計(jì)模式

       首先我們?cè)跇I(yè)務(wù)邏輯層設(shè)計(jì)時(shí),，必須首先確定是采用面向過(guò)程還是面向?qū)ο蟮哪Ｊ絹?lái)設(shè)計(jì),。 下面我們就將針對(duì)開(kāi)篇介紹的幾種模式進(jìn)行分別介紹，錯(cuò)誤之處請(qǐng)大

家批評(píng)指出,。我們首先來(lái)講解過(guò)程式的2類邏輯層的架構(gòu)模式,。

      過(guò)程式模式

       1、事務(wù)腳本模式

           事務(wù)腳本模式是面向過(guò)程的模式,，那么我們就不會(huì)采用面向?qū)ο蟮脑O(shè)計(jì)思想,。這種模式是將業(yè)務(wù)代碼映射到用戶的操作中。簡(jiǎn)單的理解就是將用戶的每個(gè)操作

都對(duì)應(yīng)一個(gè)方法,，那么這個(gè)方法就是我們這里講的事務(wù)腳本,。 當(dāng)然這里的“事務(wù)”就是指我們平時(shí)說(shuō)的業(yè)務(wù)流程,，“腳本”則是我們說(shuō)的流程中的相應(yīng)操作方法。這里

需要注意的是 ,不要認(rèn)為數(shù)據(jù)庫(kù)操作的相應(yīng)方法也屬于腳本中的內(nèi)容,，我們通常還是將數(shù)據(jù)訪問(wèn)層單獨(dú)的書(shū)寫(xiě),，只不過(guò)腳本中調(diào)用而已。

           通常,，事務(wù)腳本模式中都是一系列的邏輯判定或者循環(huán)或其他方式,，通過(guò)一系列的函數(shù)調(diào)用來(lái)實(shí)現(xiàn)業(yè)務(wù)流程的。通常來(lái)說(shuō)一般業(yè)務(wù)比較單一或者不是很復(fù)雜的

系統(tǒng)功能,，通過(guò)該模式實(shí)現(xiàn)起來(lái)會(huì)比較簡(jiǎn)單,。而且如果業(yè)務(wù)流程中的變化較為頻繁的話不建議使用該模式來(lái)做。我們認(rèn)為,，我們對(duì)于這類簡(jiǎn)單的功能,，我們沒(méi)有必要花

費(fèi)較大的代價(jià)去設(shè)計(jì)領(lǐng)域模型和其他方面的考慮。

          事務(wù)腳本模式的一大優(yōu)勢(shì)就是很簡(jiǎn)單,，沒(méi)有開(kāi)始時(shí)的額外代價(jià),，它可以很好的進(jìn)行快速的應(yīng)用程序開(kāi)發(fā)，一般情況下來(lái)說(shuō),，如果一個(gè)項(xiàng)目的時(shí)間緊迫,，邏輯簡(jiǎn)

單，并且使用強(qiáng)大的開(kāi)發(fā)工具時(shí),，我們可以使用這樣的模式來(lái)進(jìn)行,，無(wú)論是成本還是開(kāi)發(fā)效率上都非常客觀,。

          我們根據(jù)上面的介紹可能認(rèn)為,，事務(wù)腳本模式的可重用性不高，并且耦合性太高,，適應(yīng)性并不好,，當(dāng)時(shí)我們?nèi)匀豢梢酝ㄟ^(guò)我們好的設(shè)計(jì)來(lái)實(shí)現(xiàn)代碼的重用，

我們可以在進(jìn)行“腳本”編寫(xiě)時(shí)將重用的部分抽象出來(lái),，寫(xiě)一個(gè)單獨(dú)的函數(shù),，以達(dá)到復(fù)用的目的。

          事務(wù)腳本模式的一個(gè)重大缺點(diǎn)就是通過(guò)這樣的設(shè)計(jì)很容易造成代碼重復(fù),，通常來(lái)說(shuō)我們很容易完成一系列的業(yè)務(wù)功能,，但是隨著應(yīng)用程序功能的增加，那么應(yīng)用

程序代碼會(huì)變成非常復(fù)雜的程序結(jié)構(gòu),，當(dāng)然我們可以通過(guò)重構(gòu)去環(huán)節(jié)該模式的這一劣勢(shì),，當(dāng)規(guī)模達(dá)到一定程度時(shí)，我們同樣沒(méi)辦法去完成重構(gòu)工作。

          通過(guò)上面的講述,，我們對(duì)事務(wù)腳本模式有了初步的認(rèn)識(shí),，那么下來(lái)我們看看我們?cè)谶M(jìn)行業(yè)務(wù)邏輯層設(shè)計(jì)時(shí)的詳細(xì)使用該模式的步驟及相關(guān)準(zhǔn)則。

          本圖描述了事務(wù)腳本模式的設(shè)計(jì)過(guò)程,，那么基本上每個(gè)系統(tǒng)流程都可以通過(guò)這樣的流程來(lái)完成設(shè)計(jì),。下面我們就針對(duì)一個(gè)簡(jiǎn)單的實(shí)例來(lái)講解下

如何通過(guò)這樣的設(shè)計(jì)流程來(lái)實(shí)現(xiàn)系統(tǒng)的功能。

            我們這里以簡(jiǎn)單的購(gòu)物流程來(lái)講述,。如何下一個(gè)訂單

            首先,、我們先來(lái)分析下用例：

            我們知道注冊(cè)的會(huì)員可以通過(guò)將產(chǎn)品添加到購(gòu)物車(chē)中，然后通過(guò)去付款模塊來(lái)進(jìn)入支付系統(tǒng),，完成訂單,。

            其次、分析出事務(wù),。

            一般來(lái)說(shuō)購(gòu)物的流程是這樣的流程,。當(dāng)然這里也不是標(biāo)準(zhǔn)的形式。

            那么我們?nèi)绾紊鲜龅膸讉€(gè)步驟的內(nèi)容,，去完成這個(gè)事務(wù)的流程,。

            這里定義的是添加到購(gòu)物車(chē)的流程，下面將給出如何將購(gòu)物車(chē)中的產(chǎn)品信息添加到訂單中的具體流程,。

            通過(guò)上面的形式基本上就完成了簡(jiǎn)單事務(wù)腳本模式的構(gòu)建，當(dāng)然我們也可以將所有的一系列的腳本封裝到一個(gè)類里面,，通過(guò)靜態(tài)方法的方式來(lái)訪問(wèn)也是可以

的,。只是組織方法的形式不同。當(dāng)然我這里提高了,，通過(guò)將腳本封裝到一個(gè)類里面，通過(guò)靜態(tài)方法的形式或者實(shí)例方法的形式都是可以的,，那么我們來(lái)講講什么時(shí)候

封裝成靜態(tài)方法,，什么時(shí)候封裝成實(shí)例方法。

            我們?nèi)绾螌?shù)據(jù)傳入給實(shí)體腳本呢,，通常我們是通過(guò)前面我們說(shuō)的對(duì)象實(shí)體來(lái)完成的,，因?yàn)閿?shù)據(jù)對(duì)象實(shí)體只是包含實(shí)體的數(shù)據(jù)信息，并不包含具體的行為,。

            那么我們來(lái)簡(jiǎn)單說(shuō)說(shuō)對(duì)象實(shí)體中的信息及格式,，我想大家用過(guò)分層結(jié)構(gòu)中的Model層的都會(huì)比較的清楚，下面我們看看，不詳細(xì)介紹了：

            我們看到了主要是通過(guò)get,；set訪問(wèn)器來(lái)實(shí)現(xiàn)的,。

            總結(jié)：業(yè)務(wù)邏輯層是將表現(xiàn)層觸發(fā)一系列事務(wù)分別實(shí)現(xiàn)，那么對(duì)業(yè)務(wù)邏輯層的建模其實(shí)就是對(duì)事務(wù)的具體實(shí)現(xiàn),，將事務(wù)映射到業(yè)務(wù)邏輯層中的不同方法上,，一

般來(lái)說(shuō)事務(wù)代碼維護(hù)起來(lái)比較難以維護(hù)，重用性低,，難以理解,。

       2、表模塊模式

            表模塊模式是對(duì)事務(wù)腳本模式的實(shí)踐總結(jié)并優(yōu)化而提出的新模式,。相比而言,，表模塊模式結(jié)構(gòu)性更強(qiáng)，總體來(lái)說(shuō),，表模塊就是就是將數(shù)據(jù)庫(kù)中的某個(gè)表上的所

有可能的操作都寫(xiě)在一個(gè)類文件中,，這個(gè)類文件中定義了該數(shù)據(jù)庫(kù)表對(duì)應(yīng)的所有的業(yè)務(wù)方法。表模塊類是一個(gè)容器,，它內(nèi)部包含了類的數(shù)據(jù)信息和相應(yīng)的行為,。表模塊

是映射數(shù)據(jù)庫(kù)表的關(guān)系，因此表模塊對(duì)應(yīng)的是數(shù)據(jù)集合,，那么無(wú)法將數(shù)據(jù)庫(kù)表中的某個(gè)行記錄進(jìn)行區(qū)分,，只能通過(guò)集合中的鍵或者索引來(lái)訪問(wèn)行記錄的信息。

            表模塊模式由于是在事務(wù)腳本模式發(fā)展的更有結(jié)構(gòu)化的模式,，那么可以說(shuō)表模塊模式雖然是面向過(guò)程的模式,，但是它朝面向?qū)ο蟮哪Ｊ揭呀?jīng)邁了很大的一步，

我們知道,在將對(duì)象模型中的數(shù)據(jù)保存到關(guān)系數(shù)據(jù)庫(kù)中時(shí),，需要使用相關(guān)的ORM工具去完成相應(yīng)的轉(zhuǎn)換,。我們知道面向?qū)ο竽Ｐ湍軌蚝莒`活、更好的對(duì)領(lǐng)域模型建模,。當(dāng)

然,，表模塊模式仍然關(guān)注的是方法，而不是對(duì)象,。

            通常我們?cè)诟玫慕Y(jié)構(gòu)設(shè)計(jì)指導(dǎo)的同時(shí),，那么我們需要考慮更多的規(guī)則，那么意味著我們需要書(shū)寫(xiě)更多的代碼,。表模塊模式的具體實(shí)例可以參考Visio Studio

中的提供的DataSet和dataTable,。

            表模塊在處理簡(jiǎn)單的實(shí)體時(shí)具有很好的優(yōu)勢(shì)，但是當(dāng)實(shí)體較復(fù)雜時(shí),，或者實(shí)體之間的關(guān)系緊密時(shí)無(wú)法很好的處理,。下面我們來(lái)看看一個(gè)簡(jiǎn)單的例子來(lái)說(shuō)明表模

式的使用。我們這里還是以剛才事務(wù)模型中的購(gòu)買(mǎi)流程來(lái)講解。

            數(shù)據(jù)庫(kù)表與表模塊類的映射關(guān)系是通過(guò).NET提供的內(nèi)存數(shù)據(jù)對(duì)象DataSet,、

DataTable來(lái)實(shí)現(xiàn),。

           我們這里的數(shù)據(jù)如果發(fā)生變化時(shí)，我們?nèi)绾螌⒆兓说膬?nèi)存中的datatable或者dataset持久化到數(shù)據(jù)庫(kù)中呢,，ADO.NET為我們提供了dataadapter,，通過(guò)這

個(gè)適配器我們完成datatable中的數(shù)據(jù)持久化到數(shù)據(jù)庫(kù)表中。具體的形式就是上圖中的流程,，UI層通過(guò)數(shù)據(jù)請(qǐng)求方法,，然后表模塊層中有相應(yīng)的方法，將發(fā)送數(shù)據(jù)請(qǐng)求訪

問(wèn)數(shù)據(jù)庫(kù),，然后數(shù)據(jù)庫(kù)返回相應(yīng)結(jié)果通過(guò)datatable或dataset來(lái)初始化表模塊類中的數(shù)據(jù)信息,，然后返回給UI層相應(yīng)的數(shù)據(jù)信息，然后綁定后顯示,。

          總結(jié)：表模塊模式相比事務(wù)腳本模式,。是我們推薦的使用模式。并且VS中自動(dòng)繼承了相應(yīng)的datatable 與datas的相應(yīng)的圖形化設(shè)計(jì)方法,，很方便的使用,。并

且內(nèi)部.NET framework 內(nèi)置了相應(yīng)的操作方法可以迅速的實(shí)現(xiàn)交互，在過(guò)程式模式中無(wú)疑是使用表模塊模式是首選方案,。

          表模塊模式更關(guān)注的是與數(shù)據(jù)庫(kù)表的映射關(guān)系,，那么可以說(shuō)表模塊模式中包含了數(shù)據(jù)模型。有一些面向?qū)ο蟮奈兜?，不過(guò)表模塊模式中并不關(guān)注業(yè)務(wù),。

      對(duì)象式模式

           我們來(lái)講述下面向?qū)ο蟮哪Ｊ街械?種方案

       1、活動(dòng)記錄模式

           我們知道業(yè)務(wù)邏輯層中的業(yè)務(wù)邏輯才是系統(tǒng)的核心,，那么我們更關(guān)注的是業(yè)務(wù)邏輯或者領(lǐng)域邏輯,。因?yàn)槲覀儽仨氷P(guān)系實(shí)體之間的交互。我們?nèi)绻麑?duì)領(lǐng)域模型建

模,。我們需要使用面向?qū)ο蟮慕嵌热シ治鲂枨蟆?nbsp;  我們先來(lái)看看基于對(duì)象模式的活動(dòng)記錄模式,。

           活動(dòng)記錄模式是在表模塊模式的基礎(chǔ)上，將表模塊的粗粒度的基于數(shù)據(jù)集上的映射細(xì)化到表中行記錄的細(xì)粒度的映射,，并且映射的對(duì)象中包含相應(yīng)的數(shù)據(jù)庫(kù)表

中的數(shù)據(jù)信息,，并且包含對(duì)象的行為。例如,，我們現(xiàn)在如果想將產(chǎn)品表中的產(chǎn)品信息映射到數(shù)據(jù)庫(kù)中的表product中的行記錄,，那么我們需要構(gòu)建一個(gè)product類,，該

類中的屬性與product表中的列信息一一對(duì)應(yīng),。并且product類中還包含該對(duì)象所有的行為。例如CRUD的操作，其他的行為等,。

           首先我們需要知道活動(dòng)記錄的優(yōu)勢(shì)是什么,？首先我的理解就是活動(dòng)記錄模式容器理解，簡(jiǎn)單,，并且目前有很多的框架支持這樣的模式,。首先就像Linq、Castle

框架都是采用這樣的模式,。,。一般情況下,，活動(dòng)記錄模式在關(guān)系型模型中可以很好的支持,。如果在應(yīng)用程序中不使用關(guān)系型模型來(lái)設(shè)計(jì)業(yè)務(wù)層的話，那么需要我們?nèi)斯?/p>

來(lái)組織,，協(xié)調(diào)活動(dòng)記錄與數(shù)據(jù)模型之間,，其實(shí)這個(gè)就可以簡(jiǎn)單的理解為數(shù)據(jù)映射,，一般的ORM框架中都提供這樣的功能。

           我們需要知道,，如果活動(dòng)記錄模式下的對(duì)象發(fā)生改變了,，那么數(shù)據(jù)庫(kù)也得跟著修改，或者數(shù)據(jù)庫(kù)表發(fā)生改變了,，那么你不得不修改對(duì)應(yīng)的活動(dòng)記錄對(duì)象及相關(guān)代碼,。

           總而言之，如果我們?cè)谑褂没顒?dòng)記錄模式的過(guò)程中如果不能保證對(duì)象模型與數(shù)據(jù)模型之間的對(duì)應(yīng)關(guān)系,，那么我們將會(huì)很快失控,，那么領(lǐng)域模型顯然能夠解決這

樣的問(wèn)題。下面我們來(lái)看下活動(dòng)記錄模式的實(shí)例,。我們還是以購(gòu)物流程為例,。

            我們可以看到區(qū)別，從原來(lái)的表模式中的通過(guò)ADO.NET提供的內(nèi)存集合表中的形式,，修改為通過(guò)對(duì)象中的屬性的形式來(lái)保存對(duì)象的數(shù)據(jù)信息,，顯然這就是表

模式與活動(dòng)記錄模式的最大區(qū)別。不過(guò)實(shí)現(xiàn)的思想上差別不大,。

            我們都知道數(shù)據(jù)庫(kù)表之間如果有關(guān)聯(lián)的話,，那么我們通過(guò)的是外鍵的形式來(lái)進(jìn)行關(guān)聯(lián)，那么我們?cè)诨顒?dòng)記錄中一般如何來(lái)標(biāo)識(shí)某個(gè)類對(duì)應(yīng)的外鍵對(duì)象信息呢,。

            那么我們?cè)谟唵沃锌赡軙?huì)有對(duì)應(yīng)的用戶ID,，不過(guò)在不同的框架中可能對(duì)外鍵對(duì)應(yīng)的對(duì)象信息的存儲(chǔ)方式會(huì)有所不同，有些框架中在外鍵對(duì)象上通過(guò)屬性的方式

返回對(duì)象的實(shí)例的應(yīng)用,。簡(jiǎn)單來(lái)說(shuō)下這2種方式的區(qū)別：例如：

            另外一種形式,。直接將User用戶的完整對(duì)象引用實(shí)例返回,。

           上面我們看到了活動(dòng)記錄模式的簡(jiǎn)單使用方式，當(dāng)然我這里沒(méi)有說(shuō)是寫(xiě)出來(lái)可以運(yùn)行的實(shí)例代碼,。只是簡(jiǎn)單的顯示了,，使用這些模式可能的用法，當(dāng)然如果大

家有更好的理解或者用法可以一起交流,。當(dāng)然活動(dòng)記錄模型一般就能滿足我們的系統(tǒng)功能,，如果說(shuō)針對(duì)業(yè)務(wù)復(fù)雜的領(lǐng)域，那么必須設(shè)計(jì)領(lǐng)域模型去完成相應(yīng)的業(yè)務(wù)邏輯

層的設(shè)計(jì),。下面我們將來(lái)介紹領(lǐng)域模型模式的相關(guān)實(shí)例,。

       2、領(lǐng)域模型模式

          我們前面講解的幾類模式,，其實(shí)說(shuō)白了都是以數(shù)據(jù)為中心進(jìn)行抽象與設(shè)計(jì)的形式,，當(dāng)然采用這樣的形式無(wú)疑是以業(yè)務(wù)中的數(shù)據(jù)為中心，并

不是關(guān)心的業(yè)務(wù)本身,。以數(shù)據(jù)為核心的設(shè)計(jì)方法一般流程如下：

          一般來(lái)說(shuō)我們目前主流的方式都是這樣的順序來(lái)執(zhí)行,。當(dāng)然通過(guò)這樣的方式的

確一般的簡(jiǎn)單應(yīng)用當(dāng)然都是沒(méi)有太大的問(wèn)題。

          有的時(shí)候我們需要同時(shí)關(guān)系對(duì)象的數(shù)據(jù)與行為,，那么顯然以數(shù)據(jù)為核心的情況就會(huì)顯得力不從心,，當(dāng)然簡(jiǎn)單的系統(tǒng)時(shí)不會(huì)有太大的體現(xiàn)，當(dāng)時(shí)當(dāng)系統(tǒng)的規(guī)模上升

到一定的程度時(shí),，哪怕添加一些新的需求時(shí),，對(duì)系統(tǒng)的影響都是致命的。

          領(lǐng)域模型關(guān)注的是系統(tǒng)期待的行為及系統(tǒng)正常工作所需要的數(shù)據(jù)流,。一般我們?cè)谠O(shè)計(jì)領(lǐng)域模型的時(shí)候需要這個(gè)領(lǐng)域的專家協(xié)助,，最后以類的形式呈現(xiàn)出來(lái)。當(dāng)然

領(lǐng)域模型模式中的實(shí)現(xiàn)方式,，大家都知道的就是有名的DDD(領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)),。

          領(lǐng)域模型設(shè)計(jì)的最終目標(biāo)就是與系統(tǒng)的概念模型匹配起來(lái)。我們可以把領(lǐng)域模型看作是概念模型的物理模型,。在一個(gè)項(xiàng)目中可以說(shuō)領(lǐng)域模型是最重要的,，最關(guān)鍵

的部分。

          領(lǐng)域模型可以看作是一系列對(duì)象之間的交互,。領(lǐng)域模型中的每一部分都需要用一個(gè)帶有行為的類來(lái)表示,。這個(gè)怎么理解呢，請(qǐng)看圖：

          訂單信息對(duì)象首先會(huì)與訂單中的產(chǎn)品對(duì)象有交互關(guān)系,，產(chǎn)品項(xiàng)與產(chǎn)品分類有

交互關(guān)系,。訂單信息與用戶買(mǎi)家有交互關(guān)系，訂單的其他信息(物流信息,、支付信息等)有交互關(guān)系,。

          例如我們常說(shuō)的記錄的系統(tǒng)日志,，不管是錯(cuò)誤日志還是其他的所有系統(tǒng)中的日志，那么我們建議的方式采用AOP的方式來(lái)處理,。那么我們來(lái)看看具體的代碼實(shí)現(xiàn)：

                具體調(diào)用的寫(xiě)日志的方法：

             具體相關(guān)的產(chǎn)品類與產(chǎn)品分類對(duì)象的使用：

         我們看到了在活動(dòng)記錄模式中會(huì)將數(shù)據(jù)訪問(wèn)層的代碼寫(xiě)在該層,，但是領(lǐng)域模型中一般不會(huì)出現(xiàn)這樣的代碼,。領(lǐng)域模型中只關(guān)心跟業(yè)務(wù)流程相關(guān)的內(nèi)容，具體的數(shù)

據(jù)持久化之類的內(nèi)容一概不關(guān)心,。領(lǐng)域模型中是一系列的對(duì)象之間的交互,，那么我們可能會(huì)關(guān)心，如何將領(lǐng)域模型中的這些對(duì)象的狀態(tài)進(jìn)行保存呢,，那么就會(huì)牽扯到對(duì)

象模型到關(guān)系型數(shù)據(jù)庫(kù)中持久化的個(gè)問(wèn)題了,，在持久化的問(wèn)題上，我們可能有幾種選擇,，一種是采用現(xiàn)有的ORM框架去實(shí)現(xiàn)對(duì)象數(shù)據(jù)的自動(dòng)持久化,，當(dāng)然這是一種解決

辦法。有時(shí)候我們是通過(guò)手動(dòng)的方式來(lái)進(jìn)行持久化,，可能就不存在這樣的問(wèn)題,。

          我們通常在持久化數(shù)據(jù)的問(wèn)題上我們希望能做到持久化的透明性，這樣就可以說(shuō)具體的業(yè)務(wù)層不需要書(shū)寫(xiě)持久化的操作代碼,，當(dāng)然我們現(xiàn)在設(shè)計(jì)的時(shí)候可能都是

要么是通過(guò)特性來(lái)實(shí)現(xiàn)持久化,，或者是通過(guò)繼承基類的方式來(lái)做持久化的操作，那么可能帶來(lái)如下的問(wèn)題,。

          一般我們知道,，一個(gè)類如果想不寫(xiě)相應(yīng)的持久化代碼還能實(shí)現(xiàn)持久化的話，那么我們只能通過(guò)動(dòng)態(tài)的注入持久化代碼的方式來(lái)實(shí)現(xiàn)這樣的持久化透明的方案,，微

軟的EntityFrameWork2.0中的POCO中的ORM方案,，就是通過(guò)這樣的方式來(lái)實(shí)現(xiàn)的。我們更關(guān)心的是代碼應(yīng)該放在何處,，是在領(lǐng)域模型中還是領(lǐng)域模型外呢,，當(dāng)然目

前的一些常見(jiàn)的框架中已有實(shí)現(xiàn)方案，其中大家熟知的NHibernate就是持久化透明的方式,，大家如果感興趣可以參考NHibernate的實(shí)現(xiàn)思路來(lái)做,。一般對(duì)于這種動(dòng)態(tài)

注入代碼的這樣的方案，這里簡(jiǎn)單介紹下可能的實(shí)現(xiàn),，由于.NET framework 中提供了一個(gè)派生自特性類型的代理類,，通過(guò)代理類來(lái)動(dòng)態(tài)的將這個(gè)類的相關(guān)功能追加到

指定的對(duì)象中，這就是所謂的動(dòng)態(tài)代理,，當(dāng)然針對(duì)某個(gè)特定的類型這樣來(lái)做,，WCF也是通過(guò)代理類的方式來(lái)實(shí)現(xiàn)這樣的動(dòng)態(tài)插入的形式,。

六、本章總結(jié)

         本章主要是對(duì)業(yè)務(wù)層建模的不同的架構(gòu)模式進(jìn)行了相應(yīng)的總結(jié)及簡(jiǎn)單說(shuō)明,，可能某些地方說(shuō)明不是特別的清晰,，當(dāng)然我也是將平時(shí)自己的業(yè)務(wù)開(kāi)發(fā)中的一些經(jīng)驗(yàn)

和總結(jié)，部分內(nèi)容是參考以前看的書(shū)上的內(nèi)容,，不足之處還請(qǐng)大家多多的指點(diǎn),，還有請(qǐng)感興趣的朋友一起交流領(lǐng)域模型的設(shè)計(jì)，包括持久化的透明的實(shí)現(xiàn)方案等,，歡迎

大家多提意見(jiàn)和建議,。本人抱著學(xué)習(xí)和寧缺毋濫的原則，寫(xiě)好每一篇,，可能看過(guò)這方面資料的同仁當(dāng)溫習(xí)下相關(guān)內(nèi)容,，沒(méi)有看過(guò)同仁希望對(duì)你們有幫助，那就是我最大

的動(dòng)力,。

七,、系列進(jìn)度

        前篇

      1、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)系列之--開(kāi)卷有益

      2,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[上篇]

      3,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[中篇](上)

      4、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[中篇](下)

      5,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)建模[下篇]

      6,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)設(shè)計(jì)規(guī)范與原則[上篇]

      7、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-系統(tǒng)設(shè)計(jì)規(guī)范與原則[下篇]

      8,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-設(shè)計(jì)模式[上篇]

      9,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-設(shè)計(jì)模式[中篇]

      10、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-設(shè)計(jì)模式[下篇]

       中篇

      11,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-企業(yè)應(yīng)用架構(gòu)

      12,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-分層[上篇]

      13、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-分層[中篇]

      14,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-分層[下篇]

      15,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-表現(xiàn)層

      16、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-服務(wù)層

      17,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-業(yè)務(wù)邏輯層

      18,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-數(shù)據(jù)訪問(wèn)層

      19、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-組件服務(wù)

      20,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-安全機(jī)制

       后篇

      21,、單機(jī)應(yīng)用、客戶端/服務(wù)器、多服務(wù),、企業(yè)數(shù)據(jù)總線全解析

      22,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-單機(jī)應(yīng)用(實(shí)例及demo)

      23、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-客戶端/服務(wù)器(實(shí)例及demo)

      24,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-多服務(wù)(實(shí)例及demo)

      25,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-企業(yè)數(shù)據(jù)總線(實(shí)例及demo)

      26、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-性能優(yōu)化(架構(gòu)瓶頸)

      27,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-完整的架構(gòu)方案實(shí)例[上篇]

      28,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-完整的架構(gòu)方案實(shí)例[中篇]

      29、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-完整的架構(gòu)方案實(shí)例[下篇]

      30,、系統(tǒng)架構(gòu)師-基礎(chǔ)到企業(yè)應(yīng)用架構(gòu)-總結(jié)及后續(xù)

八、下篇預(yù)告

        下一篇我們將會(huì)開(kāi)始講解軟件設(shè)計(jì)中最重要也是最基本的技能-設(shè)計(jì)模式,，希望大家多多提出已經(jīng),，后面3篇我們將會(huì)講解如何在項(xiàng)目中使用設(shè)計(jì)模式及使用設(shè)計(jì)

模式需要注意的事項(xiàng),將會(huì)舉例說(shuō)明每個(gè)設(shè)計(jì)模式可能出現(xiàn)的場(chǎng)景。希望大家持續(xù)關(guān)注,！