概述

今天的內(nèi)容主要來自《軟件架構(gòu)模式》第一章，覺得還不錯(cuò)，所以分享給大家。

分層架構(gòu)

分層架構(gòu)是一種很常見的架構(gòu)模式，它也叫N層架構(gòu)。這種架構(gòu)是大多數(shù)Jave EE應(yīng)用的實(shí)際標(biāo)準(zhǔn)，因此很多的架構(gòu)師，設(shè)計(jì)師，還有程序員都知道它。許多傳統(tǒng)IT公司的組織架構(gòu)和分層模式十分的相似。所以它很自然的成為大多數(shù)應(yīng)用的架構(gòu)模式。

模式分析

分層架構(gòu)模式里的組件被分成幾個(gè)平行的層次，每一層都代表了應(yīng)用的一個(gè)功能(展示邏輯或者業(yè)務(wù)邏輯)。盡管分層架構(gòu)沒有規(guī)定自身要分成幾層幾種，大多數(shù)的結(jié)構(gòu)都分成四個(gè)層次:展示層，業(yè)務(wù)層，持久層，和數(shù)據(jù)庫(kù)層。如表1-1，有時(shí)候，業(yè)務(wù)層和持久層會(huì)合并成單獨(dú)的一個(gè)業(yè)務(wù)層，尤其是持久層的邏輯綁定在業(yè)務(wù)層的組件當(dāng)中。因此，有一些小的應(yīng)用可能只有3層，一些有著更復(fù)雜的業(yè)務(wù)的大應(yīng)用可能有5層或者更多的分層。

分層架構(gòu)中的每一層都著特定的角色和職能。舉個(gè)例子，展示層負(fù)責(zé)處理所有的界面展示以及交互邏輯，業(yè)務(wù)層負(fù)責(zé)處理請(qǐng)求對(duì)應(yīng)的業(yè)務(wù)。架構(gòu)里的層次是具體工作的高度抽象，它們都是為了實(shí)現(xiàn)某種特定的業(yè)務(wù)請(qǐng)求。比如說展示層并不需要關(guān)心怎樣得到用戶數(shù)據(jù)，它只需在屏幕上以特定的格式展示信息。業(yè)務(wù)層并不關(guān)心要展示在屏幕上的用戶數(shù)據(jù)格式，也不關(guān)心這些用戶數(shù)據(jù)從哪里來。它只需要從持久層得到數(shù)據(jù)，執(zhí)行與數(shù)據(jù)有關(guān)的相應(yīng)業(yè)務(wù)邏輯，然后把這些信息傳遞給展示層。

分層架構(gòu)的一個(gè)突出特性是組件間關(guān)注點(diǎn)分離 (separation of concerns)。一個(gè)層中的組件只會(huì)處理本層的邏輯。比如說，展示層的組件只會(huì)處理展示邏輯，業(yè)務(wù)層中的組件只會(huì)去處理業(yè)務(wù)邏輯。多虧了組件分離，讓我們更容易構(gòu)造有效的角色和強(qiáng)力的模型。這樣應(yīng)用變的更好開發(fā)，測(cè)試，管理和維護(hù)。

關(guān)鍵概念

注意表1-2中每一層都是封閉的。這是分層架構(gòu)中非常重要的特點(diǎn)。這意味request必須一層一層的傳遞。舉個(gè)例子，從展示層傳遞來的請(qǐng)求首先會(huì)傳遞到業(yè)務(wù)層，然后傳遞到持久層，最后才傳遞到數(shù)據(jù)層。

那么為什么不允許展示層直接訪問數(shù)據(jù)層呢。如果只是獲得以及讀取數(shù)據(jù)，展示層直接訪問數(shù)據(jù)層，比穿過一層一層來得到數(shù)據(jù)來的快多了。這涉及到一個(gè)概念:層隔離。

層隔離就是說架構(gòu)中的某一層的改變不會(huì)影響到其他層:這些變化的影響范圍限于當(dāng)前層次。如果展示層能夠直接訪問持久層了，假如持久層中的SQL變化了，這對(duì)業(yè)務(wù)層和展示層都有一定的影響。這只會(huì)讓應(yīng)用變得緊耦合，組件之間互相依賴。這種架構(gòu)會(huì)非常的難以維護(hù)。

從另外一個(gè)方面來說，分層隔離使得層與層之間都是相互獨(dú)立的，架構(gòu)中的每一層的互相了解都很少。為了說明這個(gè)概念的牛逼之處，想象一個(gè)超級(jí)重構(gòu)，把展示層從JSP換成JSF。假設(shè)展示層和業(yè)務(wù)層的之間的聯(lián)系保持一致，業(yè)務(wù)層不會(huì)受到重構(gòu)的影響，它和展示層所使用的界面架構(gòu)完全獨(dú)立。

然而封閉的架構(gòu)層次也有不便之處，有時(shí)候也應(yīng)該開放某一層。如果想往包含了一些由業(yè)務(wù)層的組件調(diào)用的普通服務(wù)組件的架構(gòu)中添加一個(gè)分享服務(wù)層。在這個(gè)例子里，新建一個(gè)服務(wù)層通常是一個(gè)好主意，因?yàn)閺募軜?gòu)上來說，它限制了分享服務(wù)訪問業(yè)務(wù)層(也不允許訪問展示層)。如果沒有隔離層，就沒有任何架構(gòu)來限制展示層訪問普通服務(wù)，難以進(jìn)行權(quán)限管理。

在這個(gè)例子中，新的服務(wù)層是處于業(yè)務(wù)層之下的，展示層不能直接訪問這個(gè)服務(wù)層中的組件。但是現(xiàn)在業(yè)務(wù)層還要通過服務(wù)層才能訪問到持久層，這一點(diǎn)也不合理。這是分層架構(gòu)中的老問題了，解決的辦法是開放某些層。如表1-3所示，服務(wù)層現(xiàn)在是開放的了。請(qǐng)求可以繞過這一層，直接訪問這一層下面的層。既然服務(wù)層是開放的，業(yè)務(wù)層可以繞過服務(wù)層，直接訪問數(shù)據(jù)持久層。這樣就非常合理。

開放和封閉層的概念確定了架構(gòu)層和請(qǐng)求流之間的關(guān)系，并且給設(shè)計(jì)師和開發(fā)人員提供了必要的信息理解架構(gòu)里各種層之間的訪問限制。如果隨意的開放或者封閉架構(gòu)里的層，整個(gè)項(xiàng)目可能都是緊耦合，一團(tuán)糟的。以后也難以測(cè)試，維護(hù)和部署。

實(shí)例

為了演示分層架構(gòu)是如何工作的，想象一個(gè)場(chǎng)景，如表1-4，用戶發(fā)出了一個(gè)請(qǐng)求要獲得客戶的信息。黑色的箭頭是從數(shù)據(jù)庫(kù)中獲得用戶數(shù)據(jù)的請(qǐng)求流，紅色箭頭顯示用戶數(shù)據(jù)的返回流的方向。在這個(gè)例子中，用戶信息由客戶數(shù)據(jù)和訂單數(shù)組組成(客戶下的訂單)。

用戶界面只管接受請(qǐng)求以及顯示客戶信息。它不管怎么得到數(shù)據(jù)的，或者說得到這些數(shù)據(jù)要用到哪些數(shù)據(jù)表。如果用戶界面接到了一個(gè)查詢客戶信息的請(qǐng)求，它就會(huì)轉(zhuǎn)發(fā)這個(gè)請(qǐng)求給用戶委托(Customer Delegate)模塊。這個(gè)模塊能找到業(yè)務(wù)層里對(duì)應(yīng)的模塊處理對(duì)應(yīng)數(shù)據(jù)(約束關(guān)系)。業(yè)務(wù)層里的customer object聚合了業(yè)務(wù)請(qǐng)求需要的所有信息(在這個(gè)例子里獲取客戶信息)。這個(gè)模塊調(diào)用持久層中的 customer dao 來得到客戶信息，調(diào)用order dao來得到訂單信息。這些模塊會(huì)執(zhí)行SQL語(yǔ)句，然后返回相應(yīng)的數(shù)據(jù)給業(yè)務(wù)層。當(dāng) customer object收到數(shù)據(jù)以后，它就會(huì)聚合這些數(shù)據(jù)然后傳遞給 customer delegate,然后傳遞這些數(shù)據(jù)到customer screen 展示在用戶面前。

從技術(shù)的角度來說，有很多的方式能夠?qū)崿F(xiàn)這些模塊。比如說在Java平臺(tái)中，customer screen 對(duì)應(yīng)的是 (JSF) Java Server Faces ,用 bean 組件來實(shí)現(xiàn) customer delegate。用本地的Spring bean或者遠(yuǎn)程的EJB3 bean 來實(shí)現(xiàn)業(yè)務(wù)層中的customer object。上例中的數(shù)據(jù)訪問可以用簡(jiǎn)單的POJP’s(Plain Old Java Objects)，或者可以用MyBatis，還可以用JDBC或者Hibernate 查詢。Microsoft平臺(tái)上，customer screen能用 .NET 庫(kù)的ASP模塊來訪問業(yè)務(wù)層中的C#模塊，用ADO來實(shí)現(xiàn)用戶和訂單數(shù)據(jù)的訪問模塊。

軟件架構(gòu)設(shè)計(jì)之分層架構(gòu)（三層架構(gòu)）

在軟件體系架構(gòu)設(shè)計(jì)中，分層式結(jié)構(gòu)是最常見，也是最重要的一種結(jié)構(gòu)。微軟推薦的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層（又或稱為領(lǐng)域?qū)樱⒈硎緦印?/p>

各層的作用：

1：數(shù)據(jù)訪問層：主要是對(duì)非原始數(shù)據(jù)（數(shù)據(jù)庫(kù)或者文本文件等存放數(shù)據(jù)的形式）的操作層，而不是指原始數(shù)據(jù)，也就是說，是對(duì)數(shù)據(jù)庫(kù)的操作，而不是數(shù)據(jù)，具體為業(yè)務(wù)邏輯層或表示層提供數(shù)據(jù)服務(wù)．

2：業(yè)務(wù)邏輯層：主要是針對(duì)具體的問題的操作，也可以理解成對(duì)數(shù)據(jù)層的操作，對(duì)數(shù)據(jù)業(yè)務(wù)邏輯處理，如果說數(shù)據(jù)層是積木，那邏輯層就是對(duì)這些積木的搭建。

3：界面層：主要表示W(wǎng)EB方式，也可以表示成WINFORM方式，WEB方式也可以表現(xiàn)成：aspx，如果邏輯層相當(dāng)強(qiáng)大和完善，無論表現(xiàn)層如何定義和更改，邏輯層都能完善地提供服務(wù)。

區(qū)分方法：

1：數(shù)據(jù)訪問層：主要看數(shù)據(jù)層里面有沒有包含邏輯處理，實(shí)際上它的各個(gè)函數(shù)主要完成各個(gè)對(duì)數(shù)據(jù)文件的操作。而不必管其他操作。

2：業(yè)務(wù)邏輯層：主要負(fù)責(zé)對(duì)數(shù)據(jù)層的操作。也就是說把一些數(shù)據(jù)層的操作進(jìn)行組合。

3：界面層：主要對(duì)用戶的請(qǐng)求接受，以及數(shù)據(jù)的返回，為客戶端提供應(yīng)用程序的訪問。

總結(jié)

分層架構(gòu)是一個(gè)很可靠的架構(gòu)模式。它適合大多數(shù)的應(yīng)用。如果你不確定在項(xiàng)目中使用什么架構(gòu)，分層架構(gòu)是可以先用著的。不過從架構(gòu)的角度上來說，選擇這個(gè)模式還要考慮很多的東西（如污水池反模式）。后面會(huì)分享更多devops和DBA方面的內(nèi)容，感興趣的朋友可以關(guān)注一下~