測試架構師：軟體架構模式之分層架構 2

示例

為了示範分層架構是如何工作的，想象一個場景，如表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原則可以幫助你确定架構是否處于反污水模式。大概有百分之二十的請求僅僅是做簡單的穿越，百分之八十的請求會做一些業務邏輯操作。然而，如果這個比例反過來，大部分的請求都是僅僅穿過層，不做邏輯操作。那麼開放一些架構層會比較好。不過由于缺少了層次隔離，項目會變得難以控制。

模式分析

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

整體靈活性

評級:低 

分析:總體靈活性是響應環境變化的能力。盡管分層模式中的變化可以隔絕起來，想在這種架構中做一些也改變也是并且費時費力的。分層模式的笨重以及經常出現的元件之間的緊耦合是導緻靈活性降低的原因。

易于部署

分析:這取決于你怎麼釋出這種模式，釋出程式可能比較麻煩，尤其是很大的項目。一個元件的小小改動可能會影響到整個程式的釋出(或者程式的大部分)。釋出必須是按照計劃，在非工作時間或者周末進行釋出。是以。分層模式導緻應用釋出一點也不流暢，在釋出上降低了靈活性。

可測試性

評級:高 

分析:因為元件都處于各自的層次中，可以模拟其他的層，或者說直接去掉層，是以分層模式很容易測試。開發者可以單獨模拟一個展示元件，對業務元件進行隔絕測試。還可以模拟業務層來測試某個展示功能。

性能

分析:盡管某些分層架構的性能表現的确不錯，但是這個模式的特點導緻它無法帶來高性能。因為一次業務請求要穿越所有的架構層，做了很多不必要的工作。

伸縮性

易開發性