FleaPHP

FleaPHP的全名是Fast-Lightweight-Extensible-Automatic PHP web application framework，是能夠自動適應各種運行環境，併兼容 PHP4 和 PHP5的PHP框架。

基本介紹

• 外文名： Fast-Lightweight-Extensible
• 簡稱：FleaPHP
• 特點：快速、輕量級，避免臃腫的結構
• 作用：提高開發效率
• 協定： BSD 協定

功能簡介

FleaPHP 框架簡單、清晰，容易理解和學習，並且有完全中文化的文檔和豐富的示例程式降低學習成本，為開發者輕鬆、快捷的創建應用程式提供幫助。

設計目標

FleaPHP 致力於c，並降低開發難度和強度，提高開發效率。

①快速、輕量級，避免臃腫的結構帶來的性能損失

由於 PHP 是解釋執行，如果花費太多資源在框架本身，顯然不適合的。就像一台計算機如果把大量的資源都花在作業系統上了，而應用程式能夠得到的資源卻少得可憐，顯然是無法讓用戶接受的。

②可擴展、開放性的架構，允許開發者引入自己的組件或者任何成熟的工具庫

框架雖然提供了許多組件，但不可能完全滿足用戶的需求。因此，框架本身應該是鬆散耦合、可擴展的。開發者可以很簡單的為框架加入新的組件。同時，框架的逐步發展也不應該影響框架的核心基礎。最後，開放性的架構讓開發者在框架中引入其他組件或者工具庫時不會遇到任何困難。例如開發者可能會使用 Smarty 來做模板引擎，以及 PEAR 中的一些庫來簡化開發工作。

③儘可能少的契約，但同時提供足夠的自動化能力，減輕開發強度

雖然契約式編程，可以讓框架本身的設計變得更簡單，開發者也能從框架獲得更多的幫助。但太過嚴格的規則和約定會明顯降低框架的適應性，為此需要對兩者進行適當的平衡。FleaPHP設計時採用儘可能少的契約，通過更複雜的實現來實現一些自動化能力。或者以最少量的配置信息來幫助框架為開發者提供服務。

④高度靈活的解決方案，提供開發應用程式的大多數基本組件

雖然現在已經有許許多多出色的工具庫可供選擇。但對於一些平常的需求來說，這些工具庫可能具有過度殺傷能力（也就是說工具庫本身提供了遠遠超過需求的功能）。由此帶來了學習難度增大、性能降低等問題。為此，FleaPHP 框架提供了一組輕量級的基本組件。這些組件被設計為擁有基本的功能和可擴展。 例如 FleaPHP 附帶的基於角色的許可權驗證組件雖然不如 phpGACL 這樣的庫功能強大，但卻能夠解決平常開發都會遇到的典型許可權驗證問題，並允許開發者自行擴展這個組件。

主要特徵

除了 MVC 模式實現、Dispatcher 調度器、模板引擎等常見功能外，FleaPHP 框架還擁有許多獨一無二的特點：

①簡單、容易理解的 MVC 模型

不像其他流行的框架，FleaPHP 提供的 MVC 模型注重簡單和容易理解。例如 FleaPHP 不要求開發者從特定的類派生自己的控制器類和業務模型類。

②易於使用、高度自動化的資料庫 CRUD 操作

FleaPHP 採用 TableDataGateway 設計模式來封裝數據表操作。FLEA_Db_TableDataGateway 類不但提供了容易使用的 CRUD 操作，還實現了數據表之間的關聯操作。同時，FleaPHP 沒有像其他框架那樣將每一行記錄都封裝為一個對象（毫無疑問這會產生明顯的性能問題），而是利用 PHP 強大的數組來保存和傳遞數據。

③儘可能少的配置

雖然像資料庫聯接信息等配置仍然是不可少的，但 FleaPHP 應用程式通常只需要設定幾個選項，即可在各種環境中運行良好。而且 FleaPHP 的所有設定都採用 PHP 數組來保存，不但容易理解，而且省掉了解析、快取等不必要的過程，提高了性能。

④高度可配置能力

雖然 FleaPHP 自動化程度很高，但 FleaPHP 同時也擁有高度的可配置能力。通過覆蓋 FleaPHP 默認的選項，開發者可以獲得最大程度的靈活性。讓開發者可以在適應現有代碼、保持開發習慣等各方面獲得好處。

⑤自動化的數據驗證和轉義

即便不做任何處理，程式將數據通過 FLEA_Db_TableDataGateway 提交到資料庫前。FleaPHP 也會自動對數據進行驗證，並轉義特殊字元，最大程度消除 SQL 注入攻擊。

⑥豐富的助手對象和組件

FleaPHP 附帶了一些非常實用的助手對象，從生成圖像驗證碼、處理檔案上傳到通用數據驗證等。這些助手對象大多是一些獨立的對象，完全不依賴於 FleaPHP 框架本身。因此開發者不但可以在 FleaPHP 之外使用這些助手對象，也可以方便的加入自己的助手對象。 組件是比助手對象更為複雜的可重用單元。這些組件包括基於角色的用戶管理、腳手架等。利用這些組件，開發者可以很快的完成一些常見任務，並能在這些組件基礎上擴展出功能更複雜的組件。

⑦與 Smarty 集成

只需要修改幾個選項，FleaPHP 應用程式就可以和流行的 Smarty 模版引擎集成。

⑧100% FREE

當然，最後一點就是 FleaPHP 是一個完全開放原始碼和文檔（不是那種滑稽的刪除了所有注釋僅能運行的代碼）、不限制使用的項目。你可以自由的學習、使用 FleaPHP，也可以在自己的應用程式中使用 FleaPHP。不管你的應用程式是否是商業套用，都不需要公開你的原始碼，從最大程度上保護了你的智慧財產權。不過如果你願意將代碼反饋到社區，那么大家都會感謝你。

自由性

FleaPHP 是一個遵循發布的開放原始碼應用程式開發框架。你可以免費獲取 FleaPHP 框架，並套用到自己的開發工作中。與流行的 GPL 協定不同，FleaPHP 遵循的 BSD 協定不要求開發者將基於 FleaPHP 框架開發的應用程式公布於眾。這很好的保護了開發者及其所屬企業的利益。更進一步，即便你基於 FleaPHP 實現了自己的產品或者對 FleaPHP 進行了修改以滿足自己的需求。你仍然不需要公布你的勞動成果。

下面是關於 BSD 協定的簡單介紹：

BSD 開源協定是一個給於使用者很大自由的協定。可以自由的使用，修改原始碼，也可以將修改後的代碼作為開源或者專有軟體再發布。當你發布使用了 BSD 協定的代碼，或者以 BSD 協定代碼為基礎做二次開發自己的產品時，需要滿足三個條件：

如果再發布的產品中包含原始碼，則在原始碼中必須帶有原來代碼中的 BSD 協定。

如果再發布的只是二進制類庫/軟體，則需要在類庫/軟體的文檔和著作權聲明中包含原來代碼中的 BSD 協定。

不可以用開原始碼的作者/機構名字和原來產品的名字做市場推廣。

BSD 協定鼓勵代碼共享，但需要尊重代碼作者的著作權。BSD 由於允許使用者修改和重新發布代碼，也允許使用或在 BSD 代碼上開發商業軟體發布和銷售，因此是對商業集成很友好的協定。很多的公司企業在選用開源產品的時候都首選 BSD 協定，因為可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。

起源

兩年多以前，我開始涉及使用 PHP 開發 Web 套用的工作。在反覆編寫一些過程式代碼後，我徹底厭倦了這種開發方式，開始懷念 C++ 中的面向對象設計。這時，正好在 ChinaUnix 上看到了shukebeita兄的精華貼。在這篇帖子裡，shukebeita 提出了一種面向對象的 PHP 套用開發方式。雖然只有一個雛形，但這已經讓我受益匪淺。

隨後，我根據 shukebeita 的思路實現了 PFC 的第一個版本（當時命名為輕量級 OO 框架）。其實說起來，根本不能稱之為框架，僅僅只有兩個類。但已經實現了一個簡單但實用的核心結構。現在回過頭來看，PFC1 實際上實現了一個 Dispatcher 模式，根據 HTTP 請求中的 action 參數調用不同的代碼。

在接下來的兩年時間，PFC 不斷翻新，最終發展到了 PFC3。該版本的 PFC 已經完整的實現了 Dispatcher、MVC 模式，並且引入了 ViewDriver 抽象層、基於角色的許可權驗證、採用 Provider 模式實現的用戶和角色信息管理、一個簡單的但帶有快取功能模板引擎等內容。期間曾經試圖將 PFC 發揚光大（笑），可惜由於工作變動和個人原因，項目進度非常緩慢，最後終於放棄了。但導致 PFC 放棄的主要原因並不是因為進度緩慢，而是因為我看到了 Web 套用開發的殺手 —— Ruby on Rails。

Ruby on Rails

Ruby on Rails（後文簡稱 RoR）是一個採用 Ruby 語言實現的快速、輕便的 Web 套用開發框架，通過契約式編程大大簡化了 Web 套用的開發工作。

所謂契約式編程，基本思想就是開發者必須嚴格遵守框架確定的一些規則和模式（例如對象命名、資料庫主鍵欄位命名等）。由於這些規則和模式的存在，框架可以自動完成許多以前需要開發者自己處理的工作。例如根據特定的名字，獲取業務對象或者數據表操作對象。更主要的原因是 RoR 實現了 ActiveRecord 模式，並且在這個基礎模式之上，擴展了許多便於開發者運算元據庫的方法。

雖然 ActiveRecord 只能處理 Create（建立）、Read（讀取）、Update（更新）、Delete（刪除）等數據表操作，以及一對一、一對多和多對多等幾種有限的數據表間關聯關係。但我們平時開發的大量應用程式，CRUD 又何嘗不是其中的主要內容呢。因此，RoR 為開發者解決了大部分日常任務，讓開發者可以集中精力到更關鍵的地方，例如業務流程的實現。

在我看到 RoR 後，明白 PFC 雖然已經解決了 MVC 模式、許可權驗證等任務，但最主要的資料庫訪問卻沒有提供任何能夠簡化開發的解決方案。經過反覆考慮，我終止了 PFC 系列，開始了一個“全新”的框架設計。

Flea1 與 FleaPHP

最初，這個新框架沿用了PFC系列的命名方式，命名為 flea1（也就是 FLEA 第一版）。在這個版本中，我試驗了一些想法，並取得了不錯的效果。

不過，我沒有採用嚴格的 ActiveRecord 模式，而是採用了類似CakePHP，一個類似 RoR 的 PHP 框架的 Model 設計。這種設計既實現了 CRUD 操作，又實現了數據表間的關聯操作。將這個最初版本的 flea1 框架套用到實際工作中後，馬上取得了立竿見影的效果。資料庫訪問工作被大大簡化，甚至連資料庫訪問代碼都不用寫了。而且對於數據表之間的關聯，也能完成自動化的處理。

接下來，我拿到了《企業套用架構模式》這本經典的設計模式書籍。經過仔細研究，並實際測試。我發現在 PHP 裡面使用 ActiveRecord 模式並不是一個很好的選擇。因為 ActiveRecord 實際上是針對數據表裡面的每一個數據行構造一個對象。這樣一來，對於 PHP 這種面向對象能力不強（尤其是 PHP4）的腳本語言來說，帶來了許多棘手的問題。

最終，flea1 的設計方案進行了一些調整，確定為現在的架構，並且框架命名為 FleaPHP。

MVC模式

MVC實際上是一系列略有不同的模式。FleaPHP採用的是passive(被動)MVC模式。

在passiveMVC模式中，Model(模型)完全不知道自己身處於MVC結構之中。換句話說，Model就是一個普通的對象，一MVC模式里的其他組成部分完全沒有關聯。

涉及對象

M代表Model，即模型，用於封裝與業務邏輯有關的代碼和數據。例如對訂單的各種計算。

V代表View,即視圖，用於呈現內容給用戶（也就是將程式運行的結果返回給瀏覽器顯示）。

例如商品列表頁面、後台登入頁面。

C代表Contronller,即控制器，用於接收用戶輸入（通過瀏覽器發起的請求），然後調用模型對於輸入的數據進行處理結果。最後將結果傳遞到視圖，從而讓用戶能夠看到自己操作的結果。例如用戶點擊刪除文章按鈕後，控制器調用操作文章的模型，刪除掉指定文章，最後通過視力顯示成功刪除文章的提示信息。

經過這樣的簡單的分離，我們就把應用程式運算元據的代碼（絕大部分web應用程式都是對數據進行操作）和處理用戶輸入輸出的代碼分離開來了。

好處

1.清晰的將應用程式分隔為獨立的部分；

2.業務邏輯代碼能夠很方便的在多處被重複使用；

3.方便開發人員分工協作；

4.如果需要，可以主方便開發人員對應用程式各個部分的代碼進行測試。

更新

對於大負載網站的重要更新

最近有用戶反映在訪問量達到數十萬pv時，FleaPHP 的快取檔案會出現破損問題。

新的 FleaPHP 1.0.70.1023 版本已經修復了這個缺陷，強烈建議所有開發者更新到最新版本。

最新版本：FleaPHP 1.0.70.1078

開發公司：起源科技

核心成員：Dualface