國產的PHP MVC框架：FleaPHP

官方網站： http://www.fleaphp.org
框架下載： http://www.fleaphp.org/download
框架API ： http://www.fleaphp.org/docs/api/index.html
開發指南： http://www.fleaphp.org/guide
框架社區： http://www.fleaphp.org/community

FleaPHP 并不是心血來潮的結果，而是作者在 Web 開發中不斷探索的成果。雖然 FleaPHP 缺乏 Zend Framework 那樣巨大的號召力，也沒有 CakePHP 和 Symfony 那樣龐大的社區。但 FleaPHP 仍然是一個值得你花時間去了解、去學習的框架。

---

FleaPHP 的設計目標

FleaPHP 致力于減少開發者創建 Web 應用程序的工作量，并降低開發難度和強度，提高開發效率。

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

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

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

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

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

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

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

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

---

FleaPHP 的主要特征

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

1. 簡單、容易理解的 MVC 模型

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

2. 易于使用、高度自動化的數據庫 CRUD 操作

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

3. 盡可能少的配置

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

4. 高度可配置能力

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

5. 自動化的數據驗證和轉義

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

6. 豐富的助手對象和組件

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

7. 與 Smarty 集成

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

8. 100% FREE

   當然，最后一點就是 FleaPHP 是一個完全開放源代碼和文檔（不是那種滑稽的刪除了所有注釋僅能運行的代碼）、不限制使用的項目。你可以自由的學習、使用 FleaPHP，也可以在自己的應用程序中使用 FleaPHP。不管你的應用程序是否是商業應用，都不需要公開你的源代碼。從最大程度上保護你的知識產權。

   當然，如果你愿意將代碼反饋到社區，那么大家都會感謝你。

請記住，FleaPHP 是一個持續發展的框架，隨時有新特性被加入到框架中。你現在需要，但 FleaPHP 尚未提供的功能，也許不久以后就出現在 FleaPHP 中了。當然，這需要你積極參與 FleaPHP 的發展，提出你的建議和意見。

---

自由的 FleaPHP

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

下面是關于 BSD 協議的簡單介紹：

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

1. 如果再發布的產品中包含源代碼，則在源代碼中必須帶有原來代碼中的 BSD 協議。
2. 如果再發布的只是二進制類庫/軟件，則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的 BSD 協議。
3. 不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。

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

---

FleaPHP的起源

兩年多以前，我開始涉及使用 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。

介紹國產的PHP MVC框架：FleaPHP