測試架構師：軟件架構模式之分層架構 3

示例

爲了演示分層架構是如何工做的，想象一個場景，如表1-4，用戶發出了一個請求要得到客戶的信息。黑色的箭頭是從數據庫中得到用戶數據的請求流，紅色箭頭顯示用戶數據的返回流的方向。在這個例子中，用戶信息由客戶數據和訂單數組組成(客戶下的訂單)。

用戶界面只管接受請求以及顯示客戶信息。它無論怎麼獲得數據的，或者說獲得這些數據要用到哪些數據表。若是用戶界面接到了一個查詢客戶信息的請求，它就會轉發這個請求給用戶委託(Customer Delegate)模塊。這個模塊能找到業務層裏對應的模塊處理對應數據(約束關係)。業務層裏的customer object聚合了業務請求須要的全部信息(在這個例子裏獲取客戶信息)。這個模塊調用持久層中的 customer dao 來獲得客戶信息，調用order dao來獲得訂單信息。這些模塊會執行SQL語句，而後返回相應的數據給業務層。當 customer object收到數據之後，它就會聚合這些數據而後傳遞給 customer delegate,而後傳遞這些數據到customer screen 展現在用戶面前。

從技術的角度來講，有不少的方式可以實現這些模塊。好比說在Java平臺中，customer screen 對應的是 (JSF) Java Server Faces ,用 bean 組件來實現 customer delegate。用本地的Spring bean或者遠程的EJB3 bean 來實現業務層中的customer object。上例中的數據訪問能夠用簡單的POJP’s(Plain Old Java Objects)，或者能夠用MyBatis，還能夠用JDBC或者Hibernate 查詢。Microsoft平臺上，customer screen能用 .NET 庫的ASP模塊來訪問業務層中的C#模塊，用ADO來實現用戶和訂單數據的訪問模塊。

注意事項

分層架構是一個很可靠的架構模式。它適合大多數的應用。若是你不肯定在項目中使用什麼架構，分層架構是再好不過的了。而後，從架構的角度上來講，選擇這個模式還要考慮不少的東西。

第一個要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。 
在這個模式中，請求流只是簡單的穿過層次，不留一點雲彩，或者說只留下一陣青煙。好比說界面層響應了一個得到數據的請求。響應層把這個請求傳遞給了業務層，業務層也只是傳遞了這個請求到持久層，持久層對數據庫作簡單的SQL查詢得到用戶的數據。這個數據按照原理返回，不會有任何的二次處理，返回到界面上。

每一個分層架構或多或少均可能遇到這種場景。關鍵在於這樣的請求有多少。80-20原則能夠幫助你肯定架構是否處於反污水模式。大概有百分之二十的請求僅僅是作簡單的穿越，百分之八十的請求會作一些業務邏輯操做。然而，若是這個比例反過來，大部分的請求都是僅僅穿過層，不作邏輯操做。那麼開放一些架構層會比較好。不過因爲缺乏了層次隔離，項目會變得難以控制。

模式分析

下面的的表裏分析了分層架構的各個方面。

總體靈活性

評級:低 
分析:整體靈活性是響應環境變化的能力。儘管分層模式中的變化能夠隔絕起來，想在這種架構中作一些也改變也是而且費時費力的。分層模式的笨重以及常常出現的組件之間的緊耦合是致使靈活性下降的緣由。

易於部署

評級:低 
分析:這取決於你怎麼發佈這種模式，發佈程序可能比較麻煩，尤爲是很大的項目。一個組件的小小改動可能會影響到整個程序的發佈(或者程序的大部分)。發佈必須是按照計劃，在非工做時間或者週末進行發佈。所以。分層模式致使應用發佈一點也不流暢，在發佈上下降了靈活性。

可測試性

評級:高 
分析:由於組件都處於各自的層次中，能夠模擬其餘的層，或者說直接去掉層，因此分層模式很容易測試。開發者能夠單獨模擬一個展現組件，對業務組件進行隔絕測試。還能夠模擬業務層來測試某個展現功能。

性能

評級:低 
分析:儘管某些分層架構的性能表現的確不錯，可是這個模式的特色致使它沒法帶來高性能。由於一次業務請求要穿越全部的架構層，作了不少沒必要要的工做。

伸縮性

評級:低 
分析:因爲這種模式以緊密耦合的趨勢在發展，規模也比較大，用分層架構構建的程序都比較難以擴展。你能夠把各個層分紅單獨的物理模塊或者乾脆把整個程序分紅多個節點來擴展分層架構，可是整體的關係過於緊密，這樣很難擴展。

易開發性

評級:容易 分析:在開發難度上面，分層架構獲得了比較高的分數。由於這種架構對你們來講很熟悉，不難實現。大部分公司在開發項目的都是經過層來區分技術的，這種模式對於大多數的商業項目開發來講都很合適。公司的組織架構和他們軟件架構之間的聯繫被戲稱爲」Conway’s law」。你能夠Google一下查查這個有趣的聯繫。