Web 金字塔式開發框架分層模型概述

如今的大部分 Web 框架都是使用金字塔式的分層架構，通常這種應用都是阻塞同步 IO 模型的編程實現，理解這種分層架構模型的實質有助於理解框架。

由於萬變不離其宗，理解這種架構後你無論這種模型如何變化實際上都是在遵照一些約定和規則，那麼理解這個模型，只要這個框架是這種架構那麼你都會掌握的很快。

首先咱們從最簡單的 MVC 三層架構提及。

file

實際上，通常框架分層就是這種分層的，這種分層模型使用時經過一個入口文件啓動框架服務，註冊一些框架依賴，而後經過路由分發將請求分發到各個控制器裏去，通常邏輯寫在控制器層，模型層作數據處理，視圖層負責展示。

隨着項目變大，協做人數變多，這種分層會不太能適應需求，那麼咱們能夠經過增長分層來解決問題。

file

咱們在模型層和控制器層中增長服務層，經過依賴注入的方式將控制反轉，能解決擴展和重用的問題，但隨着項目繼續擴大，咱們又要增長一層。

file

咱們再分一層，將數據修改獲取邏輯放到儲藏庫層，模型只負責模型定義，這樣多個程序員就能夠工做在不一樣的層上。

理論上咱們能夠無限分層，不斷的拆分將業務分層拆的更細。可是有的場景中咱們須要作一些操做其實不能很好的分層，由於有的業務可能用到，有的業務可能不會用到，同時因爲分層咱們製造了許多組件和分層之間的依賴，在這樣的系統中面向對象設計和編碼變的重要。

此時引進了一個新的概念 AOP ，既面向切面編程

file

上圖的藍色就是切面，面向切面編程，這種編程方法就是在須要的地方實現一個切面，把一些須要作但不是每一個業務都要作的東西放到這裏去作，如中間件、過濾器、攔截器、事件通知、觀察者都算是這種切面的實現之一。

總結

金字塔分層模型是阻塞 IO 編程的經常使用處理方式。

分層會帶來業務低耦合及加強程序複用性，但同時也會帶來業務邏輯代碼變得複雜。

面向對象編程時爲了解決大型項目的複雜性問題而產生的編程方法，有些人說這個不重要或者沒有用頗有多是作的項目還不夠大還不夠複雜，或者是根本不涉及到協做開發的緣由，亦或者是真的是要使用底層語言作高性能的開發，而語言自己不支持。

金字塔式架構開發，業務平行展開難度較大，這種架構在人員分組上 5-7 人通常會達到極限，此時即便增長人手也不會增長開發速度和效率。解決這個問題的就是微服務或者是扁平化的基於消息傳遞的面向消息編程。

世界上不止阻塞 IO 編程，還有多線程、協程，也有非阻塞 IO 異步編程語言，它們使用的編程模型和金字塔分層模型是有區別的，但在理解和使用上難度更高些。