為什麼還要寫一個PHP框架?

NO IMAGE

背景

事情源於在做框架選型的時候,我們對業務需要的技術棧進行了分析,發現我們需要的框架只需要包含路由、資料庫、Redis、日誌,就可以滿足需求了,大家討論後開始著手框架的選擇。

選型

討論框架選型時部分人意見偏向使用Laravel、Yii這種富功能框架,這些框架提供的功能是完全可以滿足業務需求的,然而反對的意見則是這些框架的學習成本比較高,新人接手不容易,而且效能較差,很多特性都用不到;而另一部分人則偏向於使用Slim、Yaf, 框架提供了基本的路由,其他功能元件則通過lib載入進來,這樣就可以按需載入各種功能元件,沒有多餘的feature,學習成本相對較小,同樣這種方案也有很多反對意見,各個元件是否能與框架結合的很好,每個lib有各自的API風格,學習成本也不小,而且如何保障各個lib的穩定性。

在這樣的情況下,就有了構件一個滿足各方需求框架的想法,團隊希望框架只包含了常用的功能元件,像Event、Behavior、Broadcasting、Notification這些很少用到的功能儘量不需要,減少不必要的學習成本;為了支援一些業務千萬級的PV,希望框架的效能足夠好;同時希望框架的可維護性較好,針對一些特殊的場景,框架能提供良好的擴充套件能力,將一些功能整合到框架裡。

最後討論決定自己開發一個框架,於是就開始了整體框架的設計。

設計

框架

首先是底層框架,設計底層框架的第一個問題就是如何管理框架的所有類及其依賴關係,對比成熟的方案有依賴注入和基於元件設計兩種方案。由於考慮後續需要對各個元件進行單元測試,選擇了依賴注入的方案。

功能元件

第二個就是框架的核心元件,框架包含的基本功能元件有資料庫、驗證、日誌、Session、Cookie、Redis等,封裝這些元件有兩種方案,可以採用外部開源的composer元件,或者自己實現,由於不同composer庫API風格不一致,而且很多庫require檔案太多,決定這些核心元件均自己實現。

易用性

要完成一件事,很多富功能框架提供了多種方式,在開發一個功能時,既可以使用A方法,又可以使用B方法,有時使用者可能很迷惑,到底應該用哪個呢;而且隨著業務迭代,到處是各種異同的使用方式。所以我們偏向於只提供單一的方式,減少使用者選擇的困惑,同時提供系統的可維護性。

擴充套件

框架包含了常用的基礎元件,為了支援使用一些特殊的元件,框架整合了composer,並且提供了基於元件的擴充套件能力。

總結

最後,經過三個多月開發,框架開發完成,並且已經成熟在幾個產品使用;框架的有些地方可能還需要不斷優化,也歡迎大家提及各種Issue,我們的目標是打造一款國內、優秀的PHP框架。

最後直接列一下框架以及開發手冊。:)

BetePHP: https://github.com/betephp/be…
中文手冊: http://betephp.com/zh/