在06、07年的時(shí)候，我寫過(guò)一些關(guān)于三層架構(gòu)方面的東西（參見(jiàn)這里），現(xiàn)在看來(lái)，覺(jué)得有很多實(shí)用性的內(nèi)容需要補(bǔ)充到里面去。我們還是先從架構(gòu)圖看起，然后一一解釋，你就會(huì)發(fā)現(xiàn)相比于兩年前，這個(gè)架構(gòu)做了哪些變化和調(diào)整。

一．三層架構(gòu)圖

二．系統(tǒng)各層次職責(zé)

1.UI（User Interface）層的職責(zé)是數(shù)據(jù)的展現(xiàn)和采集，數(shù)據(jù)采集的結(jié)果通常以Entity object提交給BL層處理。

  Web表示我們常用的B/S應(yīng)用，WinForm表示我們常用的C/S應(yīng)用。

NETwork層以Socket的方式提供服務(wù)給客戶端。

Service層用于將業(yè)務(wù)或數(shù)據(jù)資源發(fā)布為服務(wù)（如WebServices）。

2.BL（Business Logic）&Platform層的職責(zé)是按預(yù)定的業(yè)務(wù)邏輯處理UI層提交的請(qǐng)求，并對(duì)核心資源進(jìn)行管理。

（1）Business Function 子層負(fù)責(zé)基本業(yè)務(wù)功能的實(shí)現(xiàn)。

（2）Business Flow 子層負(fù)責(zé)將Business Function子層提供的多個(gè)基本業(yè)務(wù)功能組織成一個(gè)完整的業(yè)務(wù)流。

（3）Platform子層用于統(tǒng)一管理有狀態(tài)的數(shù)據(jù)和資源。

（4）注意：Transaction只能在BusinessFlow/Platform層開(kāi)啟。

（5）BL最好是沒(méi)有狀態(tài)的，而必需的狀態(tài)管理可以放到Platform中的某些模塊/子系統(tǒng)進(jìn)行。如此可增強(qiáng)系統(tǒng)的可伸縮性。

（6）Cache子層用于緩存系統(tǒng)常用的數(shù)據(jù)信息，Cache對(duì)于提供系統(tǒng)的并發(fā)量和吞吐能力起到至關(guān)重要的作用。Cache可以分為以下幾類：

   StaticCache：如果某數(shù)據(jù)表中的數(shù)據(jù)是靜態(tài)的、不會(huì)發(fā)生變化的，那就非常容易，我們只需要在系統(tǒng)啟動(dòng)的時(shí)候，將其加載到內(nèi)存，以后每次從內(nèi)存讀取數(shù)據(jù)即可。

   HotCache：如果數(shù)據(jù)表中的記錄非常多，并且修改方面只會(huì)有Insert操作，那么我們可以使用HotCache，把那些經(jīng)常使用的記錄緩存在內(nèi)存中，并且可設(shè)定超時(shí)機(jī)制刪除內(nèi)存中長(zhǎng)期不使用的記錄。

   SyncEntityCache：如果我們的某個(gè)數(shù)據(jù)表中的數(shù)據(jù)會(huì)發(fā)生變化（增刪改），但是變化的頻率比較低，但是我們的系統(tǒng)對(duì)這個(gè)表的數(shù)據(jù)的實(shí)時(shí)性的敏感度也特別高，那這時(shí)候我們就需要用到【實(shí)時(shí)同步的實(shí)體緩存】，這個(gè)緩存中的數(shù)據(jù)在任何時(shí)候都與數(shù)據(jù)表中的數(shù)據(jù)是完全一致的。

   RefreshCache：如果數(shù)據(jù)表中的數(shù)據(jù)會(huì)發(fā)生變化（增刪改），但是變化的頻率非常低，而恰巧我們的系統(tǒng)對(duì)數(shù)據(jù)實(shí)時(shí)性的敏感度也不是特別高，那我們可以使用定時(shí)刷新的緩存。

   SubObjectCache：如果某個(gè)數(shù)據(jù)表的修改經(jīng)常是Insert和Update操作，但是無(wú)論如何Update，每條記錄有些固定欄位的值都是不會(huì)發(fā)生變化的，那我們可以把這些不會(huì)發(fā)生變化的欄位封裝在一個(gè)【子對(duì)象SubObject】中，然后在內(nèi)存中緩存這些子對(duì)象。

3．DataAccess層的職責(zé)是提供全面的資源訪問(wèn)功能支持，并向上層屏蔽資源的來(lái)源。

BEM（Business Entity Manager）子層負(fù)責(zé)從數(shù)據(jù)庫(kù)中存取資源。

DB Adapter子層負(fù)責(zé)屏蔽數(shù)據(jù)庫(kù)類型的差異。

ORM子層負(fù)責(zé)提供對(duì)象－關(guān)系映射的功能。

Relation子層提供ORM無(wú)法完成的基于關(guān)系（Relation）的數(shù)據(jù)訪問(wèn)功能。

4．Entity側(cè)層跨越UI/BL&Platform/DataAccess層，在這些層之間傳遞數(shù)據(jù)。Entity側(cè)層中包含三類Entity，如下圖所示：

5.DB層可以采用數(shù)據(jù)庫(kù)分散放置、讀寫分離策略來(lái)支持超大并發(fā)。圖中數(shù)據(jù)庫(kù)名稱，M代表Master（主庫(kù)），S代表Slave（從庫(kù)）。

6.Tools層，架構(gòu)圖中還一個(gè)虛線表示的Tools層，之所以用虛線，是因?yàn)樗⒉徽娴氖窍到y(tǒng)交付的一部分，它并不實(shí)現(xiàn)系統(tǒng)的邏輯功能。但它的存在是如此的重要，特別是在我們的開(kāi)發(fā)和測(cè)試階段。它的主要作用有：

（1）DataMonitor：能將數(shù)據(jù)庫(kù)中最重要的信息方便的呈現(xiàn)給工程師，比如重要表和超大表的記錄數(shù)等。

（2）DataChecker：直接對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)進(jìn)行完整性、一致性檢查。使我們能最及時(shí)的發(fā)現(xiàn)業(yè)務(wù)邏輯在數(shù)據(jù)處理方面的重大失誤和錯(cuò)漏。

（3）DataRepairer：當(dāng)發(fā)現(xiàn)了數(shù)據(jù)錯(cuò)誤并對(duì)程序的bug進(jìn)行修正后，Tools能夠?qū)?shù)據(jù)進(jìn)行補(bǔ)充或修復(fù)。以使后續(xù)開(kāi)發(fā)和測(cè)試能立即繼續(xù)進(jìn)行。

三．ASPect

ASPect貫穿于系統(tǒng)各層，是系統(tǒng)的橫切關(guān)注點(diǎn)。通常采用AOP技術(shù)來(lái)對(duì)橫切關(guān)注點(diǎn)進(jìn)行建模和實(shí)現(xiàn)。

1．Securtiy ASPect：用于對(duì)整個(gè)系統(tǒng)的Security提供支持。

2．ErrorHandling ASPect：整個(gè)系統(tǒng)采用一致的錯(cuò)誤/異常處理方式。

3．Log ASPect：用于系統(tǒng)異常、日志記錄、業(yè)務(wù)操作記錄等。

（1）通常我們會(huì)記錄相鄰兩層的交互接口所引發(fā)的所有異常的詳細(xì)信息，包括方法調(diào)用的堆棧幀、調(diào)用方法的參數(shù)的具體值。（參考這里）

（2）通常我們會(huì)跟蹤相鄰兩層的交互接口的每個(gè)方法執(zhí)行所消耗的時(shí)間，用于檢查系統(tǒng)的性能瓶頸在哪些地方。（參考這里）

（3）通常我們會(huì)記錄所有數(shù)據(jù)庫(kù)訪問(wèn)異常的詳細(xì)信息，包括sql語(yǔ)句內(nèi)容、各參數(shù)的具體值。（參考這里）

（4）在測(cè)試階段，通常我們會(huì)記錄所有每個(gè)事務(wù)訪問(wèn)數(shù)據(jù)表的順序，通過(guò)對(duì)比這些順序，我們可以發(fā)現(xiàn)可能出現(xiàn)死鎖的地方，從而加以調(diào)整。（DataRabbit內(nèi)置支持）

（5）另外，一些重要的作業(yè)操作我們也會(huì)記錄到日志。

四．規(guī)則

1．系統(tǒng)各層次及層內(nèi)部子層次之間都不得跨層調(diào)用。

2．使用Entity object 在各個(gè)層之間傳遞數(shù)據(jù)，而不是關(guān)系型的DataSet。只有在特殊情況下，才將UI綁定到DataTable，比如返回的結(jié)果集沒(méi)有Entity與之對(duì)應(yīng)的時(shí)候。

3．UI層和BL層禁止出現(xiàn)任何SQL語(yǔ)句。

4．對(duì)于每一個(gè)數(shù)據(jù)庫(kù)表（Table）都有一個(gè)DB Entity class與之對(duì)應(yīng)，針對(duì)每一個(gè)Entity class都會(huì)有一個(gè)BEM Class與之對(duì)應(yīng)。

5．有些跨數(shù)據(jù)庫(kù)或跨表的操作（如復(fù)雜的聯(lián)合查詢）也需要由相應(yīng)的BEM Class來(lái)提供支持。

6．對(duì)于相對(duì)簡(jiǎn)單的系統(tǒng)，可以考慮將Business Function子層和Business Flow 子層合并為一個(gè)。

五．錯(cuò)誤與異常

        異常可以分為系統(tǒng)異常（如網(wǎng)絡(luò)突然斷開(kāi)）和業(yè)務(wù)異常（如用戶的輸入值超出最大范圍），業(yè)務(wù)異常必須被轉(zhuǎn)化為業(yè)務(wù)執(zhí)行的結(jié)果。

1．     DataAccess層不得向上層隱藏任何異常（該層拋出的異常幾乎都是系統(tǒng)異常）。

2．     要明確區(qū)分業(yè)務(wù)執(zhí)行的結(jié)果和系統(tǒng)異常。比如驗(yàn)證用戶的合法性，如果對(duì)應(yīng)的用戶ID不存在，不應(yīng)該拋出異常，而是返回（或通過(guò)out參數(shù)）一個(gè)表示驗(yàn)證結(jié)果的枚舉值，這屬于業(yè)務(wù)執(zhí)行的結(jié)果。但是，如果在從數(shù)據(jù)庫(kù)中提取用戶信息時(shí)，數(shù)據(jù)庫(kù)連接突然斷開(kāi)，則應(yīng)該拋出系統(tǒng)異常。

3．     在有些情況下，BL層應(yīng)根據(jù)業(yè)務(wù)的需要捕獲某些系統(tǒng)異常，并將其轉(zhuǎn)化為業(yè)務(wù)執(zhí)行的結(jié)果。比如，某個(gè)業(yè)務(wù)要求試探指定的數(shù)據(jù)庫(kù)是否可連接，這時(shí)BL就需要將數(shù)據(jù)庫(kù)連接失敗的系統(tǒng)異常轉(zhuǎn)換為業(yè)務(wù)執(zhí)行的結(jié)果。

4．     UI層(包括Service層)除了從調(diào)用BL層的API獲取的返回值來(lái)查看業(yè)務(wù)的執(zhí)行結(jié)果外，還需要截獲所有的系統(tǒng)異常，并將其解釋為友好的錯(cuò)誤信息呈現(xiàn)給用戶。

5．     當(dāng)WebService的參數(shù)或返回值需要是復(fù)雜類型――即架構(gòu)圖中的Service Entity，則Service Entity應(yīng)該在對(duì)應(yīng)的*.EntranceParaDef.dll中定義。WebService定義的方法中的復(fù)雜類型應(yīng)該使用Xml字符串代替，而Xml字符串和復(fù)雜類型對(duì)象之間的轉(zhuǎn)換應(yīng)當(dāng)在*.Entrance.dll中實(shí)現(xiàn)。

      不知您有何補(bǔ)充或建議，請(qǐng)指點(diǎn)一二，呵呵。

it知識(shí)庫(kù)：我的架構(gòu)經(jīng)驗(yàn)小結(jié)（四）－－ 實(shí)戰(zhàn)中演化的三層架構(gòu)，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。