本篇我們將討論分層架構模式。

分層架構模式是一種n層模式，其中組件按照水平層次進行組織。這是設計大多數(shù)軟件的傳統(tǒng)方法，旨在實現(xiàn)自我獨立。這意味著所有組件之間相互連接，但彼此之間不相互依賴。

這種架構模式有四個層，每個層中的模塊性和組件之間都有連接。從上到下，它們分別是：

展示層：包含與展示相關的所有類別。

業(yè)務層：它包含業(yè)務邏輯。

持久層：用于處理對象關系映射等功能

數(shù)據(jù)庫層：存儲所有數(shù)據(jù)。

在這種情況下，各層是封閉的，也就是說請求必須從頂部到底部經(jīng)過所有層。這樣設計有兩個原因，一個是將所有"相似"的組件放在一起，另一個原因是提供層次的隔離。

進一步說明，將“相似”的組件放在一起意味著與某個層相關的所有內(nèi)容都保留在該單一層中。這樣可以清晰地區(qū)分各種組件，并且有助于將相似的代碼集中在一個位置。通過隔離各層，它們相互之間變得獨立。因此，例如，如果我們想將數(shù)據(jù)庫從Oracle服務器更改為SQL服務器，這將對數(shù)據(jù)庫層產(chǎn)生重大影響，但不會影響其他層。同樣，假設您有一個自定義的業(yè)務層，并且想要將其更改為業(yè)務規(guī)則引擎，如果我們有一個良好定義的分層架構，這種更改不會影響其他層。

分層架構模式可以在所提及的層級之外進行修改，增加其他層級。這被稱為混合分層架構。例如，在業(yè)務層和持久化層之間可以添加一個服務層。然而，這并不是理想的設計，因為現(xiàn)在業(yè)務層必須經(jīng)過服務層才能到達持久化層。這個請求通過服務層并沒有任何價值。我們稱之為架構陷阱反模式。請求經(jīng)過各層時，在每個層中幾乎沒有或沒有執(zhí)行任何邏輯。

唯一解決這個問題的方法是將可選的層級設置為開放層。這意味著如果可選的層級對發(fā)送的請求有任何增值作用，請求就會經(jīng)過該層級。如果沒有增值作用，請求將直接繞過該層級，進入相關的下一層級。在上圖中可以看到這種情況，請求繞過了服務層，從業(yè)務層直接進入持久化層。

然而需要注意的是，通過設置開放層，我們削弱了層級之間獨立的好處。如果我們想替換持久化層，就必須考慮到開放的服務層和業(yè)務層。這兩個層級現(xiàn)在都與持久化層耦合在一起。因此，雖然向系統(tǒng)中添加開放層非常容易，但我們不允許這種情況發(fā)生。我們必須在不損害架構的情況下解決問題。

結論

分層架構是最簡單的軟件架構模式。如果要設計一個基本的應用程序，用戶數(shù)量很少（<100-200），并且在投入使用后不會有太多的需求變化，那么這是最好的軟件架構模式。與其他模式相比，這種架構模式的實現(xiàn)成本非常低。

以下是分層架構模式的優(yōu)劣分析。

優(yōu)點

這種架構模式易于測試，因為組件屬于特定的層級。因此，它們可以單獨測試。

由于大多數(shù)應用程序自然而然地按層級工作，所以這種架構模式簡單易實現(xiàn)。

缺點

盡管可以對特定層進行更改，但這并不容易，因為應用程序是一個單一的單元。而且，層之間的耦合關系往往會增加難度。這也使得擴展變得困難。

它必須作為一個單一的單元部署，因此對特定層的更改意味著整個系統(tǒng)必須重新部署。

它的規(guī)模越大，請求經(jīng)過多個層級所需的資源就越多，從而導致性能問題。