PHP開源：easy-php －從 0 開始構建一個屬于你自己的 PHP 框架
從0開始構建一個屬于你自己的PHP框架
如何構建一個自己的PHP框架
為什么我們要去構建一個自己的PHP框架？可能絕大多數的人都會說“市面上已經那么多的框架了，還造什么輪子？”。我的觀點“造輪子不是目的，造輪子的過程中汲取到知識才是目的”。
那怎樣才能構建一個自己的PHP框架呢？大致流程如下：
入口文件 ----> 注冊自加載函數
----> 注冊錯誤(和異常)處理函數
----> 加載配置文件
----> 請求
----> 路由
---->（控制器 <----> 數據模型）
----> 響應
----> json
----> 視圖渲染數據
除此之外我們還需要單元測試、nosql支持、接口文檔支持、一些輔助腳本等。最終我的框架目錄如下：
框架目錄一覽
app [PHP應用目錄]
├── demo [模塊目錄]
│ ├── controllers [控制器目錄]
│ │ └── Index.php [默認控制器文件，輸出json數據]
│ ├── logics [邏輯層，主要寫業務邏輯的地方]
│ │ ├── exceptions [異常目錄]
│ │ ├── gateway [一個邏輯層實現的gateway演示]
│ │ ├── tools [工具類目錄]
│ │ └── UserDefinedCase.php [注冊框架加載到路由前的處理用例]
│ └── models [數據模型目錄]
│ └── TestTable.php [演示模型文件，定義一一對應的數據模型]
├── config [配置目錄]
│ ├── demo [模塊配置目錄]
│ │ ├── config.php [模塊自定義配置]
│ │ └── route.php [模塊自定義路由]
│ ├── common.php [公共配置]
│ ├── database.php [數據庫配置]
│ └── nosql.php [nosql配置]
docs [接口文檔目錄]
├── apib [Api Blueprint]
│ └── demo.apib [接口文檔示例文件]
├── swagger [swagger]
framework [Easy PHP核心框架目錄]
├── exceptions [異常目錄]
│ ├── CoreHttpException.php[核心http異常]
├── handles [框架運行時掛載處理機制類目錄]
│ ├── Handle.php [處理機制接口]
│ ├── ErrorHandle.php [錯誤處理機制類]
│ ├── ExceptionHandle.php [未捕獲異常處理機制類]
│ ├── ConfigHandle.php [配置文件處理機制類]
│ ├── NosqlHandle.php [nosql處理機制類]
│ ├── LogHandle.php [log機制類]
│ ├── UserDefinedHandle.php[用戶自定義處理機制類]
│ └── RouterHandle.php [路由處理機制類]
├── orm [對象關系模型]
│ ├── Interpreter.php [sql解析器]
│ ├── DB.php [數據庫操作類]
│ ├── Model.php [數據模型基類]
│ └── db [數據庫類目錄]
│ └── Mysql.php [mysql實體類]
├── nosql [nosql類目錄]
│ ├── Memcahed.php [Memcahed類文件]
│ ├── MongoDB.php [MongoDB類文件]
│ └── Redis.php [Redis類文件]
├── App.php [框架類]
├── Container.php [服務容器]
├── Helper.php [框架助手類]
├── Load.php [自加載類]
├── Request.php [請求類]
├── Response.php [響應類]
├── run.php [框架應用啟用腳本]
frontend [前端源碼和資源目錄]
├── src [資源目錄]
│ ├── components [vue組件目錄]
│ ├── views [vue視圖目錄]
│ ├── images [圖片]
│ ├── ...
├── app.js [根js]
├── app.vue [根組件]
├── index.template.html [前端入口文件模板]
├── store.js [vuex store文件]
public [公共資源目錄，暴露到萬維網]
├── dist [前端build之后的資源目錄，build生成的目錄，不是發布分支忽略該目錄]
│ └── ...
├── index.html [前端入口文件,build生成的文件，不是發布分支忽略該文件]
├── index.php [后端入口文件]
runtime [臨時目錄]
├── logs [日志目錄]
├── build [php打包生成phar文件目錄]
tests [單元測試目錄]
├── demo [模塊名稱]
│ └── DemoTest.php [測試演示]
├── TestCase.php [測試用例]
vendor [composer目錄]
.git-hooks [git鉤子目錄]
├── pre-commit [git pre-commit預commit鉤子示例文件]
├── commit-msg [git commit-msg示例文件]
.babelrc [babel配置文件]
.env [環境變量文件]
.gitignore [git忽略文件配置]
build [php打包腳本]
cli [框架cli模式運行腳本]
LICENSE [lincese文件]
logo.png [框架logo圖片]
composer.json [composer配置文件]
composer.lock [composer lock文件]
package.json [前端依賴配置文件]
phpunit.xml [phpunit配置文件]
README-CN.md [中文版readme文件]
README.md [readme文件]
webpack.config.js [webpack配置文件]
yarn.lock [yarn lock文件]
框架模塊說明：
入口文件
定義一個統一的入口文件，對外提供統一的訪問文件。對外隱藏了內部的復雜性，類似企業服務總線的思想。
// 載入框架運行文件
require('../framework/run.php');
自加載模塊
使用spl_autoload_register函數注冊自加載函數到__autoload隊列中，配合使用命名空間，當使用一個類的時候可以自動載入(require)類文件。注冊完成自加載邏輯后，我們就可以使用use和配合命名空間申明對某個類文件的依賴。
錯誤和異常模塊
腳本運行期間：
- 錯誤:
通過函數set_error_handler注冊用戶自定義錯誤處理方法，但是set_error_handler不能處理以下級別錯誤，E_ERROR、 E_PARSE、 E_CORE_ERROR、 E_CORE_WARNING、 E_COMPILE_ERROR、 E_COMPILE_WARNING，和在 調用 set_error_handler() 函數所在文件中產生的大多數 E_STRICT。所以我們需要使用register_shutdown_function配合error_get_last獲取腳本終止執行的最后錯誤，目的是對于不同錯誤級別和致命錯誤進行自定義處理，例如返回友好的提示的錯誤信息。
[ file: framework/hanles/ErrorHandle.php ]
- 異常:
通過函數set_exception_handler注冊未捕獲異常處理方法，目的捕獲未捕獲的異常，例如返回友好的提示和異常信息。
[ file: framework/hanles/ExceptionHandle.php ]
配置文件模塊
加載框架自定義和用戶自定義的配置文件。
[ file: framework/hanles/ConfigHandle.php ]
輸入和輸出
- 定義請求對象：包含所有的請求信息
- 定義響應對象：申明響應相關信息
框架中所有的異常輸出和控制器輸出都是json格式，因為我認為在前后端完全分離的今天，這是很友善的，目前我們不需要再去考慮別的東西。
[ file: framework/Request.php ]
[ file: framework/Response.php ]
路由模塊
通過用戶訪問的url信息，通過路由規則執行目標控制器類的的成員方法。我在這里把路由大致分成了四類：
傳統路由
domain/index.php?module=Demo&contoller=Index&action=test&username=test
pathinfo路由
domain/demo/index/modelExample
用戶自定義路由
// 定義在config/moduleName/route.php文件中，這個的this指向RouterHandle實例
$this->get('v1/user/info', function (Framework\App $app) {
return 'Hello Get Router';
});
微單體路由
我在這里詳細說下這里所謂的微單體路由，面向SOA和微服務架構大行其道的今天，有很多的團隊都在向服務化邁進，但是服務化過程中很多問題的復雜度都是指數級的增長，例如分布式的事務，服務部署，跨服務問題追蹤等等。這導致對于小的團隊從單體架構走向服務架構難免困難重重，所以有人提出來了微單體架構，按照我的理解就是在一個單體架構的SOA過程，我們把微服務中的的各個服務還是以模塊的方式放在同一個單體中，比如：
app
├── UserService [用戶服務模塊]
├── ContentService [內容服務模塊]
├── OrderService [訂單服務模塊]
├── CartService [購物車服務模塊]
├── PayService [支付服務模塊]
├── GoodsService [商品服務模塊]
└── CustomService [客服服務模塊]
如上，我們簡單的在一個單體里構建了各個服務模塊，但是這些模塊怎么通信呢？如下：
App::$app->get('demo/index/hello', [
'user' => 'TIGERB'
]);
通過上面的方式我們就可以松耦合的方式進行單體下各個模塊的通信和依賴了。與此同時，業務的發展是難以預估的，未來當我們向SOA的架構遷移時，很簡單，我們只需要把以往的模塊獨立成各個項目，然后把App實例get方法的實現轉變為RPC或者REST的策略即可，我們可以通過配置文件去調整對應的策略或者把自己的，第三方的實現注冊進去即可。
[ 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 [Logics層目錄下gateway邏輯目錄]
├── Check.php [接口]
├── CheckAppkey.php [檢驗app key]
├── CheckArguments.php [校驗必傳參數]
├── CheckAuthority.php [校驗訪問權限]
├── CheckFrequent.php [校驗訪問頻率]
├── CheckRouter.php [網關路由]
├── CheckSign.php [校驗簽名]
└── Entrance.php [網關入口文件]
網關入口類主要負責網關的初始化，代碼如下：
// 初始化一個：必傳參數校驗的check
$checkArguments = new CheckArguments();
// 初始化一個：app key check
$checkAppkey = new CheckAppkey();
// 初始化一個：訪問頻次校驗的check
$checkFrequent = new CheckFrequent();
// 初始化一個：簽名校驗的check
$checkSign = new CheckSign();
// 初始化一個：訪問權限校驗的check
$checkAuthority = new CheckAuthority();
// 初始化一個：網關路由規則
$checkRouter = new CheckRouter();
// 構成對象鏈
$checkArguments->setNext($checkAppkey)
->setNext($checkFrequent)
->setNext($checkSign)
->setNext($checkAuthority)
->setNext($checkRouter);
// 啟動網關
$checkArguments->start(
APP::$container->getSingle('request')
);
實現完成這個gateway之后，我們如何在框架中去使用呢？在logic層目錄中我提供了一個user-defined的實體類，我們把gateway的入口類注冊到UserDefinedCase這個類中，示例如下：
/**
* 注冊用戶自定義執行的類
*
* @var array
*/
private $map = [
// 演示 加載自定義網關
'App\Demo\Logics\Gateway\Entrance'
];
這樣這個gateway就可以工作了。接著說說這個UserDefinedCase類，UserDefinedCase會在框架加載到路由機制之前被執行，這樣我們就可以靈活的實現一些自定義的處理了。這個gateway只是個演示，你完全可以天馬行空的組織你的邏輯～
視圖View去哪了？由于選擇了完全的前后端分離和SPA(單頁應用), 所以傳統的視圖層也因此去掉了，詳細的介紹看下面。
[ file: app/* ]
使用Vue作為視圖
源碼目錄
完全的前后端分離，數據雙向綁定，模塊化等等的大勢所趨。這里我把我自己開源的vue前端項目結構 easy-vue 移植到了這個項目里，作為視圖層。我們把前端的源碼文件都放在frontend目錄里，詳細如下，你也可以自己定義：
frontend [前端源碼和資源目錄，這里存放我們整個前端的源碼文件]
├── src [資源目錄]
│ ├── components [編寫我們的前端組件]
│ ├── views [組裝我們的視圖]
│ ├── images [圖片]
│ ├── ...
├── app.js [根js]
├── app.vue [根組件]
├── index.template.html [前端入口文件模板]
└── store.js [狀態管理，這里只是個演示，你可以很靈活的編寫文件和目錄]
build步驟
yarn install
DOMAIN=http://你的域名 npm run dev
編譯后
build成功之后會生成dist目錄和入口文件index.html在public目錄中。非發布分支.gitignore文件會忽略這些文件，發布分支去除忽略即可。
public [公共資源目錄，暴露到萬維網]
├── dist [前端build之后的資源目錄，build生成的目錄，不是發布分支忽略該目錄]
│ └── ...
├── index.html [前端入口文件,build生成的文件，不是發布分支忽略該文件]
[ file: frontend/* ]
數據庫對象關系映射
數據庫對象關系映射ORM(Object Relation Map)是什么？按照我目前的理解：顧名思義是建立對象和抽象事物的關聯關系，在數據庫建模中model實體類其實就是具體的表，對表的操作其實就是對model實例的操作。可能絕大多數的人都要問“為什么要這樣做，直接sql語句操作不好嗎？搞得這么麻煩！”，我的答案：直接sql語句當然可以，一切都是靈活的，但是從一個項目的 可復用，可維護, 可擴展 出發，采用ORM思想處理數據操作是理所當然的，想想如果若干一段時間你看見代碼里大段的難以閱讀且無從復用的sql語句，你是什么樣的心情。
市面上對于ORM的具體實現有thinkphp系列框架的Active Record,yii系列框架的Active Record,laravel系列框架的Eloquent(據說是最優雅的)，那我們這里言簡意賅就叫ORM了。接著為ORM建模，首先是ORM客戶端實體DB：通過配置文件初始化不同的db策略，并封裝了操作數據庫的所有行為，最終我們通過DB實體就可以直接操作數據庫了，這里的db策略目前我只實現了mysql(負責建立連接和db的底層操作)。接著我們把DB實體的sql解析功能獨立成一個可復用的sql解析器的trait，具體作用：把對象的鏈式操作解析成具體的sql語句。最后，建立我們的模型基類model,model直接繼承DB即可。最后的結構如下：
├── orm [對象關系模型]
│ ├── Interpreter.php [sql解析器]
│ ├── DB.php [數據庫操作類]
│ ├── Model.php [數據模型基類]
│ └── db [數據庫類目錄]
│ └── Mysql.php [mysql實體類]
DB類使用示例
/**
* DB操作示例
*
* findAll
*
* @return void
*/
public function dbFindAllDemo()
{
$where = [
'id' => ['>=', 2],
];
$instance = DB::table('user');
$res = $instance->where($where)
->orderBy('id asc')
->limit(5)
->findAll(['id','create_at']);
$sql = $instance->sql;
return $res;
}
Model類使用示例
// controller 代碼
/**
* model example
*
* @return mixed
*/
public function modelExample()
{
try {
DB::beginTransaction();
$testTableModel = new TestTable();
// find one data
$testTableModel->modelFindOneDemo();
// find all data
$testTableModel->modelFindAllDemo();
// save data
$testTableModel->modelSaveDemo();
// delete data
$testTableModel->modelDeleteDemo();
// update data
$testTableModel->modelUpdateDemo([
'nickname' => 'easy-php'
]);
// count data
$testTableModel->modelCountDemo();
DB::commit();
return 'success';
} catch (Exception $e) {
DB::rollBack();
return 'fail';
}
}
//TestTable model
/**
* Model操作示例
*
* findAll
*
* @return void
*/
public function modelFindAllDemo()
{
$where = [
'id' => ['>=', 2],
];
$res = $this->where($where)
->orderBy('id asc')
->limit(5)
->findAll(['id','create_at']);
$sql = $this->sql;
return $res;
}
服務容器模塊
什么是服務容器？
服務容器聽起來很浮，按我的理解簡單來說就是提供一個第三方的實體，我們把業務邏輯需要使用的類或實例注入到這個第三方實體類中，當需要獲取類的實例時我們直接通過這個第三方實體類獲取。
服務容器的意義？
用設計模式來講：其實不管設計模式還是實際編程的經驗中，我們都是強調“高內聚，松耦合”，我們做到高內聚的結果就是每個實體的作用都是極度專一，所以就產生了各個作用不同的實體類。在組織一個邏輯功能時，這些細化的實體之間就會不同程度的產生依賴關系，對于這些依賴我們通常的做法如下：
class Demo
{
public function __construct()
{
// 類demo直接依賴RelyClassName
$instance = new RelyClassName();
}
}
這樣的寫法沒有什么邏輯上的問題，但是不符合設計模式的“最少知道原則”，因為之間產生了直接依賴，整個代碼結構不夠靈活是緊耦合的。所以我們就提供了一個第三方的實體，把直接依賴轉變為依賴于第三方，我們獲取依賴的實例直接通過第三方去完成以達到松耦合的目的，這里這個第三方充當的角色就類似系統架構中的“中間件”，都是協調依賴關系和去耦合的角色。最后，這里的第三方就是所謂的服務容器。
在實現了一個服務容器之后，我把Request,Config等實例都以單例的方式注入到了服務容器中，當我們需要使用的時候從容器中獲取即可，十分方便。使用如下：
// 注入單例
App::$container->setSingle('別名，方便獲取', '對象/閉包/類名');
// 例，注入Request實例
App::$container->setSingle('request', function () {
// 匿名函數懶加載
return new Request();
});
// 獲取Request對象
App::$container->getSingle('request');
Nosql模塊
提供對nosql的支持，提供全局單例對象，借助我們的服務容器我們在框架啟動的時候，通過配置文件的配置把需要的nosql實例注入到服務容器中。目前我們支持redis/memcahed/mongodb。
如何使用？如下，
// 獲取redis對象
App::$container->getSingle('redis');
// 獲取memcahed對象
App::$container->getSingle('memcahed');
// 獲取mongodb對象
App::$container->getSingle('mongodb');
接口文檔生成和接口模擬模塊
通常我們寫完一個接口后，接口文檔是一個問題，我們這里使用Api Blueprint協議完成對接口文檔的書寫和mock(可用)，同時我們配合使用Swagger通過接口文檔實現對接口的實時訪問(目前未實現)。
Api Blueprint接口描述協議選取的工具是snowboard,具體使用說明如下：
接口文檔生成說明
cd docs/apib
./snowboard html -i demo.apib -o demo.html -s
open the website, http://localhost:8088/
接口mock使用說明
cd docs/apib
./snowboard mock -i demo.apib
open the website, http://localhost:8087/demo/index/hello
[ file: docs/* ]
單元測試模塊
基于phpunit的單元測試，寫單元測試是個好的習慣。
如何使用？
tests目錄下編寫測試文件，具體參考tests/demo目錄下的DemoTest文件,然后運行：
vendor/bin/phpunit
測試斷言示例：
/**
* 演示測試
*/
public function testDemo()
{
$this->assertEquals(
'Hello Easy PHP',
// 執行demo模塊index控制器hello操作，斷言結果是不是等于'Hello Easy PHP'
App::$app->get('demo/index/hello')
);
}
[ file: tests/* ]
Git鉤子配置
目的規范化我們的項目代碼和commit記錄。
- 代碼規范：配合使用php_codesniffer，在代碼提交前對代碼的編碼格式進行強制驗證。
- commit-msg規范：采用ruanyifeng的commit msg規范，對commit msg進行格式驗證，增強git log可讀性和便于后期查錯和統計log等, 這里使用了 Treri 的commit-msg腳本，Thx~。
輔助腳本
cli腳本
以命令行的方式運行框架，具體見使用說明。
build腳本
打包PHP項目腳本，打包整個項目到runtime/build目錄，例如：
runtime/build/App.20170505085503.phar
<?php
// 入口文件引入包文件即可
require('runtime/build/App.20170505085503.phar');
[ file: ./build ]
如何使用?
執行：
- composer install
- chmod -R 777 runtime
網站服務模式:
步驟 1: yarn install
步驟 2: DOMAIN=http://localhost:666 npm run demo
步驟 3: cd public
步驟 4: php -S localhost:666
訪問網站：http://localhost:666/index.html
訪問接口：http://localhost:666/Demo/Index/hello
demo如下：
客戶端腳本模式:
php cli --method=<module.controller.action> --<arguments>=<value> ...
例如, php cli --method=demo.index.get --username=easy-php
獲取幫助:
使用命令 php cli 或者 php cli --help
問題和貢獻
不足的地方還有很多，如果大家發現了什么問題，可以給我提 issue 或者PR。
或者你覺著在這個框架實現的細節你想了解的，一樣可以給我提 issue ，后面我會總結成相應的文章分享給大家。
如何貢獻？
cp ./.git-hooks/* ./git/hooks
然后正常發起PR即可, 所有的commit我都會進行代碼格式(psr)驗證和commit-msg驗證，如果發生錯誤，請按照提示糾正即可。
項目地址： https://github.com/TIGERB/easy-php
TODO
- 懶加載優化框架加載流程
- 性能測試和優化
- 變更Helper助手類的成員方法為框架函數，簡化使用提高生產效率
- 提供更友善的開發api幫助
- 模塊支持數據庫nosql自定義配置
- 支持mysql主從配置
- ORM提供更多鏈式操作api
- 框架log行為進行級別分類
- 想辦法解決上線部署是配置文件問題
- 基于phar文件和git webhook自動化打包部署
- ...
項目主頁：http://www.baiduhome.net/lib/view/home/1494224376777