framework.php

PHP Framework

這是一個用於中小型團隊開發的框架

特點

• 非常簡潔
• 支持Swoole
• 提供最常用的功能
• 容易擴展和替換需要功能
• 提供了簡單的主從庫方案
• 提供了簡單的分錶分庫機制
• 提供了簡單的數據批量加載方案
• 提供適用大多數情的行/列表緩存
• 提供了直接的靜態文件方案

使用示例

一個簡單的個人博客bybzmt/blog.php

性能

基於此框架的個人博客bybzmt/blog.php有非常強大的性能

• 環境: Debian9 + nginx/1.10.3 + PHP/7.0.27 + Swoole/2.1.2-alpha
• 硬件: i7-7700T + 16G + ssd/sm951
• ab -c 10 -n 100000 -k http://blog/

模式	靜態文件	首頁(2篇博客)	首頁(10篇博客)
Fpm	4705	1507	1237
Swoole	26607	3276	2084

• 靜態文件，相當echo "Hello Word!"，只是內容更多
• 由於計算力所限10條博客時有較大下降，這可以通過堆機器解決
• 由於使用了行/列表緩存此測試實際只訪問了memcache並沒有訪問mysql

典型目錄結構

 ├── assets       资源目录(如:字体文件等)
├── config
│   ├── dev      开发环境配置
│   ├── product  生产环境配置
├── index.php    项目入口
├── library      其它与composer不兼容的库
├── src
│   ├── Admin    管理后台
│   ├── Api      app接口端
│   ├── Backend  内部(内网)接口
│   ├── Common   公共代码目录
│   ├── Console  控制台
│   ├── Wap      手机Web端
│   └── Web      Web端
├── static
│   ├── admin    后台静态文件
│   └── web      Web端静态文件
├── tests        单元测试目录
├── var          可读写目录(如:模板缓存等)
└── vendor       composer库

啟動流程

1. 設置環境變量
2. 引入composer自動加載
3. 啟動Front::run()
4. 根據請求找到對應模塊
5. 啟動對應模塊Bootstrap::run()
6. 初始化請求上下文對像
7. 路由請求得到控制器
8. 執行控制器

Context上下文對像

由於Swoole是一種常駐內存模式，全局變量的生命週期是應用級，而不同於fpm模式下只是請求級的。 全局變量能在不同請求間保持，所以$_GET、$_POST等原方法都不能用了。 這裡框架給每個請求實例化一個Context對像，將所有跟當前請求相關的數據存到Context對像中。

Context對像還負責組件按層級加載和替換功能。

如上面博客中:

1. WebContext對像繼承於CommonContext對像
2. CommonContext對像繼承於FrameworkContext對像

當初始化組件時Context對像會首先在自己的命名空間中尋找對應組件，如果沒找到則讓父級Context進行初始化。 這樣子可以很方便的擴展和替換自己所需要的組件。

api:

• Context->request 請求對像
• Context->response 響應對像
• Context->initComponent($name, ...$args) 實例化組件
• Context->getComponent($name) 得到實例化的組件
• Context->now() 當前時間，相當於$_SERVER['REQUEST_TIME']

Request、Response對像

Request對像是直接使用的swoole_http_request

Response對像同樣是直接使用swoole_http_response

在Fpm模式中框架實現一個兼容層保持了和Swoole中一樣的api

組件

框架裡把所有跟Context對像有關的對像都實現為了Component, 主要是提供快速實例化功能，不需要反复傳遞Context對像。

另外Component也現實了一些便捷方法方便在任意組件內使用。

路由

路由並沒有採用開放式映射式的，而是採用了註冊式路由，優點是路由比較乾淨。

路由項目位於bybzmt/router.php

如果不喜歡可以替換為你喜歡的庫，框架替換組件非常簡單。

業務模型

框架推薦使用領域模型模式，使用: Service、Table、Row(Domain)結構

• Service層主要是按大的模塊劃分，如Blog模塊，用戶模塊主要是負責“啟頭”和各種不方便劃分到領域對像中的業務
• Table層只負責數據工作，包括sql組織，緩存維護，分錶分庫工作等
• Row層則是業務層

需要注意的是不要把數據展示的工作寫到Service、Table、Row中去，它位只負責提供最基本的數據， 按頁面、api要求組織對應的數據結構應該在控制器、視圖中實現

資料庫

數據庫分為提供基礎功能的Table類，提供分錶功能的TableSplit類。 另外有提供緩存功能的TableRowCache trait。 任何用戶的表應都該繼承於Table或TableSplit類，並當需要緩存時引入TableRowCache trait即可。

注意分錶和緩存都只是對Table類中的get/gets/insert/update/delete這幾個操作進行了支持。 當用SQL直接進行數據操作時需要手動維護相關緩存或分錶功能。

批量加載

框架提供了LazyRow加載方法，當實例化時只是記錄id，到訪問屬性才再試圖批量加載。

• 優點：可以轉換一般的循環中的單條加載變為批量加載
• 缺點：當對應的id查無此記錄時，LazyRow己實例化，需作額外判斷

助手層

框架提供了一些常用功能方便使用

• Captcha 驗證碼生成
• Resource 資源獲取(如: mysql)
• Security 安全限制
• Session 會話機制(替代$_SESSION)
• SQLBuilder sql構建​​工具
• StaticFile 響應靜態文件
• Utils 實用工具

Cache緩存

這個緩存跟上面Table中的緩存沒有關係，它是指用戶自己維護的緩存。 盡量讓不同類型的緩存用不同的類去管理，避免key衝突。

模板

框架沒有提供模板功能，建議直接使現現有第三方模板程序。 (如:Twig)

寫在最後

1. 框架的各功能並沒有想適應所有環境，只需要在80%情況下可用就行了，特殊情況在具體的項目中可以特殊處理。

2. 框架的代碼不多，如果想用盡量把代碼都讀一遍。