[學習] CodeIgniter 走馬觀花[下]

日期:2006-09-26  作者:喜騰小二  來源:PHPChina


Controller
Controller 類是所有控制器的基礎類。Controller 實例化時會將
CI_Input、CI_Benchmark、CI_Config、CI_URI、CI_Output、CI_Language 的實例複製到 Controller
實例的成員變數中。然後根據應用程式設定,自動載入檔案。

但是這裡作者顯然沒有處理好,所以不得不用 `global $IN, $BM, $CFG,
$URI, $LANG, $OUT;` 這樣的全域變數來傳遞幾個重要的物件實例。

Controller 本身並沒提供 model、helper
的載入服務。這些都由 CI_Loader 來提供。但是,CI_Loader 的各種載入服務,卻又用 get_instance() 獲取控制器的實例,然後調用
Controller(控制器都是 Controller 的繼承類哦)的 _ci_initialize()、_ci_init_database()
等方法來做初始化。

神啊!救救我吧!這種錯綜復雜的關係,真的要人命啊!

Controller 的 $ci_is_loaded
成員變數用於儲存已經載入的物件實例。所以每次用 Controller::_ci_load_model() 載入模組後,都要將該模組登記到
$ci_is_loaded,以避免重複載入。

Controller 裡麵大部分是一些初始化各種服務的方法,例如初始化資料庫、Model
的方法。還有就是用 _ci_scaffolding() 調用 CodeIgniter 的“腳手架”功能。

對 Controller
的設計,沒什麼好說的,一個字:爛!


CI_Loader
CI_Loader 提供各種載入服務,例如載入
Model、Helper、View 等。但是(我真的很痛恨“但是”這個詞),CI_Loader 卻需要 Controller 來完成初始化。那麼又是誰來調用
CI_Loader 呢?答案是
Controller。

這種緊密的耦合,完全是沒有必要的!


控制器開始執行
分析到這裡,終於進入應用程式的程式碼了。應用程式控制器中,可以用
$this->load 來載入各種服務,然後就可以調用這些載入的服務了。

雖然 CodeIgniter 在
CI_Base、Controller 和 CI_Loader 上設計很糟糕,但開發者如果不在乎這些,那麼開發過程還是很愉快的。

下麵我們再來看看
CodeIgniter 主要服務的特點。


資料庫訪問
與大部分框架不同,CodeIgniter 的 Model
類沒有提供資料庫訪問功能。所有資料庫操作都是透過資料庫驅動程式來進行的。

所有資料庫驅動均繼承自 CI_DB 類。等等,我怎麼找不到 CI_DB
類的定義呢?因為 CI_DB 類是在 Controller 中用 `eval('class CI_DB extends CI_DB_driver { }');`
這行程式碼來定義的。定義這樣一個空殼,估計是作者為以後擴充資料庫驅動留下的伏筆。

CodeIgniter 的資料庫驅動,功能都很簡單,和 AdoDB
Lite 類似,但是缺乏 AdoDB Lite 那麼多的延伸庫。我個人認為反倒不如用 AdoDB Lite 來取代這部分。當然了,CodeIgniter
目前已經有不少資料庫驅動了,所以取代成 AdoDB Lite 好處不多。

CodeIgniter 也提供了一個 ActiveRecord
實現,不過這個 ActiveRecord 可沒有一點半點的“ORM”能力。但是 CodeIgniter 的 ActiveRecord
不需要為每一個資料表都構造一個實例。通常一個實例就可以處理多個資料表的操作。例如 `$query =
$this->db->get('mytable');` 和 `$query = $this->db->get('mytable2');`
就可以分別取得 mytable 和 mytable2 的資料。

說實話,作者可能用錯了名字。CodeIgniter
中的“ActiveRecord”實際上是表資料入口模式——TableDataGateway。

CodeIgniter 中的
ActiveRecord 基本上隻是一個對資料表進行 CRUD 操作的公共介麵。沒有提供 RoR、CakePHP、FleaPHP
等框架俱有的資料表關聯自動處理能力。和自己寫 SQL 相比,沒什麼優勢。唯一的好處就是作者所說的可以讓 ActiveRecord 來生成這些簡單的 SQL
陳述式,而不用自己寫,提高應用程式在不同資料庫之間移植的能力。


“腳手架”功能
CodeIgniter
中提供了基本的“腳手架”功能,可以用幾行程式碼即實現一個對某個資料表進行 CRUD 的介麵。這和 phpMyAdmin
中的資料浏覽、編輯页面類似,當然功能要簡單得多。

“腳手架”有什麼實用價值,眾說紛纭。但普遍認同的一點就是“腳手架”功能為處於開發初期的應用程式提供了管理資料的介麵。開發者可以在後期取代掉“腳手架”的介麵。

但是,CodeIgniter
也太簡單了,就隻有 CRUD 操作,還不如 phpMyAdmin 好用。


其他
CodeIgniter
還有許多其他的類和助手。這些類基本上都屬於提供各種協助服務的範疇。有些類很不錯,像圖片操作。但大部分類和助手實在太簡單,缺乏實用價值。像資料驗證助手,隻能做很基本的驗證,在絕大多數應用程式裡麵都不能滿足要求。


總結
咳——咳——,總結時間到了。

再次鄭重申明:本文所有文字均為作者個人理解和感想。作者盡量做到客觀,但人非聖賢,難免參雜個人好惡在其中。所以如果妳看到不爽的文字,請自動無視,謝謝合作!


CodeIgniter
是一個:簡單不簡潔、好用但可能不夠用的工俱。

幾個步驟就可以讓妳的應用程式跑起來,所以簡單。因為簡單,所以好用。但糟糕的設計增加了復雜度,簡單的表麵下是錯綜復雜的物件關係。因為過於簡單,所以可能不夠用。

如果妳隻是開發很簡單的應用程式,那麼
CodeIgniter 完全可以滿足妳的需求。而且妳也會獲得愉快的體驗。

但如果應用程式俱有一定的復雜度,CodeIgniter
就可能起到反作用。因為 CodeIgniter 在幾個主要類上的糟糕設計,妳的應用程式最終也會受到牽連。而且 CodeIgniter
缺乏許多必須的服務,例如訪問控制、使用者管理、自動化的資料表關聯處理、復雜快取等。

這些服務對於一個較為復雜的應用程式來說都是必須的。如果用
CodeIgniter 作為應用程式框架,那麼這些服務都需要自己實現。這時 CodeIgniter
帶來的好處就很少了。


黃金時段,播出廣告
和 CodeIgniter 一樣好用,跟
CakePHP、Symfony、Zend Framework 一樣“差不多”強大 —— FleaPHP
是妳最貼心的選擇!

請不要扔雜物,此廣告屬於公益性質!

FleaPHP 是一個開放源程式碼,完全相容 PHP4 和
PHP5,易學易用,高度模組化和開放的應用程式開發框架。

FleaPHP 相比
CodeIgniter,有下列優勢:

-  一樣的好用。如果妳看不懂英文,那麼 FleaPHP
就更好用了,因為文檔、源程式碼注釋都是中文的;
-  更多的功能。包括自動化資料表關聯處理、訪問控制、使用者管理等;
-  更高的效能。也許妳不知道,一個典型的
CodeIgniter 應用程式需要載入 17 至 25 個檔案,而 FleaPHP 應用程式隻需要 10 - 18
個檔案,而且還提供更多的功能。同時,FleaPHP 高度的模組化結構,使得應用程式最少隻需要 6
個檔案就可以執行(還包括基本的資料庫訪問服務);
-  中文社區,可以更容易的獲得說明;
-  清晰的設計架構,可以很容易的擴充和修改。

FleaPHP
相比 CakePHP、Symfony、Zend Framework 的不足:

-  沒有那麼大的名氣和人氣;
-  缺少對 Ajax
的支援;
-  缺乏進階的快取服務;
-  文檔沒有那麼齊全。

目前,FleaPHP
團隊正在努力完善文檔,並豐富功能。如果妳有興趣,可以花上2分鐘看看下麵這篇文章的開頭,然後再決定是否要花更多的時間來瞭解 FleaPHP。

http://www.fleaphp.org/node/36

<<<返回技術中心

技術文章

站內新聞

我要啦免费统计