Web 框架雜記

codeIgniter 將 控制器與模型 物件都定位在函式 的集合,比較接近靜態類別的函式集如 Math.abs ..Math.pie 。

django 則沒說明 控制器與模型 需要用物件來設計,給使用者自行抉擇的空間,都採用 module 內包含數 func 來實做, 但支援的 orm 可以讓存取資料表等同於物件的操作。

如果沒特別設計,依照兩個框架最原始的介紹與建議的基礎開發,兩者在控制器的差異不大,但 django 較沒有去解釋物件的用法,大都是用在各種工具元件的情況 如 Form , Session,因為原先物件導向的設計就比較偏向元件的重用,而不是函式的集合,所以 django 較符合原始意義。

那 codeIgniter 這樣設計有什麼好處呢?

將 PHP 按照順序執行的流程,整理成物件的生命週期,雖然異於物件導向原始的意義,但流程控制較容易掌控,在程式規模擴增時,也讓尋找程式碼實際檔案變的更加容易,且也提供 library 的方式來讓使用者擺放擴增的 classes。

但其 library 對於各式的 classes 的引入,不夠 friendly ,對檔案與類別名字有所限制。

整體來說,物件雖重用性不高,但對於限制程式擴增的模式來說,有良好的效果,如能搭配 modules 的概念,系統也能成長到一定的規模。

對於 php 還沒有支援命名空間的版本來說,當用 函式 來組織,很容易會有名稱的衝突,如果要退一步,就要用各種累贅的命名慣例,而透過多一層類別封裝函式,解決了這種情況,但遇到控制器與模型名稱衝突時,可能還是需要靠命名空間來解決,抑或是這種設計容易造成不具意義的物件(函式集),所以命名才會成為煩惱吧。

django 的彈性

….