天天看點

軟體架構模式—分層架構

作者:MobotStone

這是軟體架構模式部落格系列第 2 章,我們将讨論分層架構模式。

分層架構模式是一種n層模式,其中元件按照水準層次進行組織。這是設計大多數軟體的傳統方法,旨在實作自我獨立。這意味着所有元件之間互相連接配接,但彼此之間不互相依賴。

軟體架構模式—分層架構

這種架構模式有四個層,每個層中的子產品性群組件之間都有連接配接。從上到下,它們分别是:

展示層:包含與展示相關的所有類别。

業務層:它包含業務邏輯。

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

資料庫層:存儲所有資料。

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

進一步說明,将“相似”的元件放在一起意味着與某個層相關的所有内容都保留在該單一層中。這樣可以清晰地區分各種元件,并且有助于将相似的代碼集中在一個位置。通過隔離各層,它們互相之間變得獨立。是以,例如,如果我們想将資料庫從Oracle伺服器更改為SQL伺服器,這将對資料庫層産生重大影響,但不會影響其他層。同樣,假設您有一個自定義的業務層,并且想要将其更改為業務規則引擎,如果我們有一個良好定義的分層架構,這種更改不會影響其他層。

軟體架構模式—分層架構

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

軟體架構模式—分層架構

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

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

結論

分層架構是最簡單的軟體架構模式。如果要設計一個基本的應用程式,使用者數量很少(<100-200),并且在投入使用後不會有太多的需求變化,那麼這是最好的軟體架構模式。與其他模式相比,這種架構模式的實作成本非常低。

以下是分層架構模式的優劣分析。

優點

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

由于大多數應用程式自然而然地按層級工作,是以這種架構模式簡單易實作。

缺點

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

它必須作為一個單一的單元部署,是以對特定層的更改意味着整個系統必須重新部署。

它的規模越大,請求經過多個層級所需的資源就越多,進而導緻性能問題。

繼續閱讀