The Art of Readable Code && High Performance Comments

時間不多,隨手筆記

最近在公司打造 某種 神奇系統,打算用 PHP MVC 框架來加速開發;在考量需求之後,發現需求種類繁多,打包成套件會比較好管理。因此這個專案就被拆解成三部份啦:

  1. 套件伺服器:提供套件版本、相依性資料供下載
  2. 套件框架:能連到套件伺服器,完成身份查驗、下載並自動安裝套件、檢查相依性
  3. 服務框架:上面那個 M-V-C 框架,搭配很多套件,可能的範例大概有
    1. 上稿:能在服務框架裡面 新增、刪除、修改 內容
    2. 套件打包:將框架裡的內容打包成套件以後,上傳到套件伺服器
    3. 檢閱:顯示 上稿系統 所輸入的各種內容
    4. 分析:會對某些 hook 登記 callback,然後把資料寫進 log 並分析

考慮到這些套件要能分別被安裝(只要滿足相依性),並且服務框架在安裝不同套件後,能夠完成多樣化的功能;原本的樣板架構也要能用套件去作更新與修正,像是 CodeIgniter 之類的 MVC Framework 顯然會有些麻煩。(麻煩 = 要寫很多程式,特別是在套件框架那區)

之所以會有這些困難,是因為 CI 不想放棄對 PHP4 的相容性,因此很多 PHP5 才出現的新特性,他們並不支援;要手動整合進去的話,又難免斧鑿痕跡太深,不修改原碼很難作到/難做得漂亮。

這時候,就只能靠框架方式來尋求解答,tada~ HMVC 提供了另一種方式的考量。相關資料可以去念 wiki,總之 module 的目錄架構能夠直接對應到框架的 model/view/controller,並且每個套件可以打包成一個 module,容易整合、安裝、移除。

目前稍微摸過了 kohana;它的架構相當簡單,也包含了一些好用的套件,例如 database, orm, cache 等等;不過如果要跟其他 ORM 整合 (例如 Doctrine) 還是要費點功夫。我手邊有之前玩過一陣子 CI + Doctrine 的設定檔,總是希望能讓 doctrine 設定檔簡單點好;每個套件都去掛一隻 autoloader 實在是有點鬱悶,而且還要從 kohana 裡得到 套件引用的順序,依次呼叫 autoloader 才能確保同名物件覆蓋的順序,與 kohana 預設相同。

由於 kohana 本身沒有使用 namespace,它的 autoloader 自然也沒將其考量在內;也就是說,要整合高度 namespace 化的 Doctrine 上去,會需要深入修改 kohana 的 autoloader (還是比自己打造快)。

另外還有套 HMVC 叫做 FuelPHP,預備這周有空來念一下;這傢伙號稱是基於 PHP 5.3,相信不可能沒利用/考慮到 namespace 這鬼東西 XD

發表迴響

分類

%d 位部落客按了讚: