（中）

因為這次發表的內容比較多比較長，為方便大家閱讀；我已分成三篇發文，大家要是有覺得有價值、感興趣可以關注此賬號或者加【PHP學習特邀群】獲取完整內容以及更多內容。

12.2MB源碼我也已經壓縮打包好了進群你就可以下載，群是開放的。

目錄（中）篇

• 輸入和輸出

• 路由模塊

• 傳統的MVC模式提倡為MCL模式

• 使用Vue作為視圖

• 數據庫對象關係映射

• 服務容器模塊

輸入和輸出

• 定義請求對象：包含所有的請求信息

• 定義響應對象：申明響應相關信息

框架中所有的異常輸出和控制.器輸出都是【json】格式，這在目前是很友善的，我們不需要再去考慮別的東西。

[ file: framework/Request.php ]

[ file: framework/Response.php ]

路.由模塊

通過用戶訪問的【url】信息，通過路.由規則執行目標控制器類的的成員方法。我在這裡把路.由大致分成了四類：

1. 傳統路.由

2. 【pathinfo】路.由

3. 用戶自定義路.由

4. 微單體路.由

• 微單體路.由

詳細說下微單體路.由；面向SOA 和 微.服務架構大行其道的今天，有很多的團隊都在向服務化邁進，但是服務化過程中很多問題的複雜程度都是指數級的增長。

知識這難免導致小的團隊從單體架構走向服務架構而艱難無比，於是就有人提出了微單體架構，就是在一個單體架構的SOA過程中把微服務中的的各個服務依舊以模塊的方式放在同一個單體中，比如：

.

通過上面的方式我們就可以進行單體下各個模塊的通信和依賴了。同時，業務的發展是難以預估的，未來當我們向SOA的架構遷移時，我們只需要把以往的模塊獨立成各個項目，再將App實例get方法的實現轉變為RPC或者REST的策略就可以了，我們可以通過配置文件去調整對應的策略或者把自己的，第三方的實現註冊進去即可。

• 傳統路.由

.

• 【pathinfo】路.由

.

• 用戶自定義路.由

.

如上，我們簡單的在一個單體裡構建了各個服務模塊，還要在這些模塊之間實現通信

如下：

.

[ file: framework/hanles/RouterHandle.php ]

傳統的MVC模式提倡為MCL模式

傳統的MVC模式包含【model-view-controller】層，絕大多時候我們會把業務邏輯寫到【controller】層或【model】層，但是慢慢的我們會發現代碼難以閱讀、維護、擴展，所以我在這裡增加了一個【logics】層。

這樣看來，我們的最終結構是這樣的

• M:【models】職責只涉及數據模型相關操作

• C: 【controllers】職責對外暴露資源，前後端分離架構下【controllers】其實就相當於【json】格式的視圖

• L: 【logics】職責靈活實現所有業務邏輯的地方

【logics】邏輯層

• 邏輯層實現網關示例：

我們在【logics】層目錄下增加了一個【gateway】目錄，然後我們就可以靈活的在這個目錄下編寫邏輯了。【gateway】的結構如下：

.

網關入口類主要負責網關的初始化

代碼如下：

.

實現完成這個【gateway】之後，應該如何在框架中去使用呢？

在【logic】層目錄中我提供了一個【user-defined】的實體類，我們把【gateway】的入口類註冊到【UserDefinedCase】這個類中

.

這樣【gateway】就可以運作了。再來說說【UserDefinedCase】類；【UserDefinedCase】會在框架加載到路.由機制之前被執行，這樣我們就可以靈活的實現一些自定義的處理了。這裡的【gateway】只是個演示，你完全可以組織你自己的邏輯～

[ file: app/* ]

使用Vue作為視圖

• 源碼目錄

完全的前後端分離，數據雙向綁定，模塊化等等。這裡我把自己vue前端項目結構 【easy-vue】移植到了這個項目裡，來作為視圖層。我們把前端的源碼文件都放在【frontend】目錄裡

詳細如下：

.

build步驟

.

編譯後

【build】成功之後會生成【dist】目錄和入口文件【index.html在public】目錄中。

.

[ file: frontend/* ]

數據庫對象關係映射

數據庫對象關係映射ORM(Object Relation Map)

市面上對於ORM的具體實現有TP系列框架的Active Record； YII系列框架的Active Record； laravel系列框架的Eloquent，那我們這裡言簡意賅就叫ORM了。

ORM建模，首先是ORM客戶端實體DB：通過配置文件初始化不同的DB策略，並封裝了操作數據庫的所有行為，最終我們通過DB

接著我們把DB實體的SQL解析功能獨立成一個可複用的SQL解析器的trait，具體作用：把對象的鏈式操作解析成具體的SQL語句。

最後，建立我們的模型基類model直接繼承DB。最後的結構如下：

.

• DB類使用示例

.

• Model類使用示例

.

.

[ file: framework/orm/* ]

服務容器模塊

• 什麼是服務容器？

簡單來說就是提供一個第三方的實體，我們把業務邏輯需要使用的類或實例注入到這個第三方實體類中，當需要獲取類的實例時我們直接通過這個第三方實體類獲取。

• 服務容器的意義？

其實不管設計模式還是實際編程的經驗中，我們都強調“高內聚，低耦合”，我們做到高內聚的結果就是每個實體的作用都極度專一，於是就產生了各個作用不同的實體類。

在組織一個邏輯功能時，這些細化的實體之間就會不同程度的產生依賴關係。

在實現了一個服務容器之後，我把Request,Config等實例都以單例的方式注入到了服務容器中，當我們需要使用的時候從容器中獲取即可：

.

[ file: framework/Container ]

完整內容請關注

.

.

閱讀更多 魚與之於漁 的文章

關鍵字: 軟件 SQL JSON