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

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

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

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

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

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

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

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

django 的彈性

….