我與 CakePHP
怎麼開始的?
在實際使用 CakePHP 前,我已經是個以設計 PHP 應用為主的工程師,也是開始體會到,程式設計其實還有蠻多煩瑣的工作必須完成,不是每天都可以接觸新玩意兒。
一個使用者在操作過程發現,好像應該加一個欄位進去,需求進到工作清單,在資料表開了對應的欄位,接著就是在表單新增一個欄位,確認資料可以塞進資料庫後,就開始著手修改畫面,簡單測試後就請使用者試試。然後使用者會發現,這個欄位並不只是要顯示而已,應該加入一些判斷,讓他更好做事,這種工作就這樣成了無限迴圈,使用的人越多,發生的頻率越高。
接著老闆突發其想,要將某某流程透過程式自動化,在需求訪談過程會驚覺,原來這個某某流程平時根本沒有標準可言,文件亂、例外狀況多,儼然就是個燙手山芋。在老闆執意進行之下,這系統還是莫名其妙出現了,接著就是操作單位與開發單位的大亂鬥,老闆見情況不妙就開始躲在一旁,在兩個單位沒能夠達成共識之前,功能的雛型就是一直晾在那裡。
最經典的還是那句話,「為什麼誰誰誰有,我們卻沒有?」,這句話可以讓一個需求衍生為全面且多樣性的功能,也可以讓開發單位被要求每天得盯著競爭對手的網站,其中的無奈可想而知。
當然,使用 CakePHP 並不會像拿了什麼寶物一樣讓那些人全部閉上嘴巴,只是在逐漸趨於追逐時效性的現實情況下,能夠有個快速滿足需求的工具會讓生活好過些。
只有 CakePHP ?
在腦子裡開始出現求生念頭時,其實懷抱著許多憧憬,當時耳聞有工具可以將 UML 資料直接轉換為程式碼,或是透過拖拉與設定就可以搞定程式,於是就貪心的把類似的工具當作目標尋找,雖然過程有接觸過 CakePHP ,但是覺得它離理想工具還有些差距,所以一開始並沒有將焦點放在它身上。即使在確認沒有那種夢幻般的工具後,我一開始是使用 Seagull PHP Framework 嘗試進行開發,發現它得花好長一段時間進入狀況,加上接觸當時的文件並不齊全,所以沒有繼續使用。
接著接觸到 Qcodo 這個程式架構,它強調可以自動產生更多、更完整的程式碼,一段放在網站上的展示影片吸引了我;只是吸引我的並不只有 Qcodo 這個工具,還包括他所使用的編輯器,因為在那個時候我還是使用 UltraEdit 這類只有提供程式碼醒目標示的工具(也就是透過各種顏色顯示程式碼,讓程式碼更容易閱讀),這才更加認為自己應該在工具的使用上多下些功夫。
很幸運的,在掙扎是否要購買 Zend Studio 時,出現了一個免費的工具 PHP Development Tool ,剛好能夠滿足比較迫切的一些需求,所以現在也還是這個工具的忠實用戶。
在 PDT 的協助之下,對 Qcodo 有比較深一層的認識,只是也開始遇到了瓶頸,因為 Qcodo 背後的開發團隊不大(初期只有一個人),使用的人也不多,加上持續發展當中,所以許多情況下得試著深入核心程式來找出問題,而能夠投入的時間有限,後來主要開發者也消失了一陣子,我就開始轉換跑道了。
期間也有試過 PRADO 與 symfony 等專案,因為複雜度較高而選擇放棄;同時間 Zend 也開始推出自己的程式架構 ,跟另一個公司所分享的 eZ Components 類似,專注在提供高品質的程式元件,並不是很吸引人。
最後,在眾多的程式架構中,我選擇了 CakePHP ,因為它的社群很活躍,進入的門檻較低,相關的介紹與教學也很豐富。
CakePHP 哪裡快?
嚴格說起來,CakePHP 的執行速度並不快,但是它的架構允許你透過各種快取來彌補執行速度不快的問題;真正快的地方是開發速度,自動產生資料增刪改查的程式、資料表的維護、多國語言的語系檔案產生以及單元測試等,這些都可以透過指令完成,而系統本身提供了豐富的元件,加上高擴充性的架構,讓 CakePHP 吸引了許多的程式開發人員。
一個典型的功能開發過程:
1.先透過工具在資料庫完成資料表建立
2.產生資料的增刪改查介面雛型
3.調整操作畫面後進行延伸功能開發
4.設計單元測試範例
5.抽出程式碼中的語言定義
6.上線前設定快取規則
7.納入權限管理設定
最值得一提的是,CakePHP 對於關聯資料的取得相當方便,許多過去要輸入大量 SQL 查詢語法才能產生的資料,在 CakePHP 中只要簡單的幾行程式就能夠做到,而且可以做完整的控制。不過這個好處只有在雛型開發時可以盡情享用,因為預設取得關聯資料的方式會產生大量資料庫查詢,這對於應用程式的速度相當不利,一些預期會需要大量使用的資料存取還是建議手動設計查詢語法。
CakePHP 的演進速度也很快,因為社群龐大,所以許多問題在自己還沒發現之前就被提出、解決了,討論群組的文章數量、網友透過部落格分享的心得以及使用各種語言的在地化社群都持續在增加當中,每隔幾分鐘就會有新資訊從世界的某個角落進入到網際網路中。
另外,CakePHP 的許多概念承襲自 Ruby on Rails ,如果是 愛好者且有 PHP 程式開發需求,CakePHP 或許是個比較快上手的選擇。
停止抱怨,開始寫程式
這個世界總是有喜歡抱怨以及聽了抱怨會擔心、害怕的人,這篇文章並不是為了對抗這種勢力而存在;我是個實際的使用者,在採用 CakePHP 後確實獲得了許多好處,希望藉由這篇文章做個分享。有人喜歡喝自己壓的柳橙汁,有人喜歡用機器壓,也有人接受工廠大量生產的濃縮還原柳橙汁,這只是選擇,別想的太嚴重。
bobju 14:31:25 on 2008 年 11 月 10 日 Permalink
呵呵, 好文! 最近正在survey PHP的framework, 看來cakePHP就對了.
溫暖暖 17:44:15 on 2009 年 10 月 20 日 Permalink
http://tzangms.com/programming/1202
可是看到這篇, 又說CakePHP很慢…@@|||
kiang 17:51:56 on 2009 年 10 月 20 日 Permalink
如同你在該篇文章看到的回應,使用一個 Framework 最主要的是能夠快速解決你的問題,而速度的比較在數值看來也許驚人,但是實際的感覺並沒有這麼大的差異,因為有許多加速的機制可以使用。一個可以快速解決你問題的工具,速度也可以接受,我想沒有什麼好挑剔的了
Ricky 16:52:12 on 2009 年 10 月 21 日 Permalink
快慢並不是衡量一個Framework的關鍵
如果真的要快die(‘hello world!’);不就解決一切問題了XD