簡述一下你用過的開源框架，說說他們的有缺點？

從語言方面：Tp與Yii都可以滿足中文使用者的需求，但是由於Yii是國際化的專案，所以程式碼註釋仍舊是英文，不過呢兩個框架的創始人依舊都是中國人，所以在交流方面還是挺方便的。

YII優點：

yii呢，自帶了一個環境檢測指令碼，它可以告訴使用者當前您的主機環境是否滿足yii框架的需求。檢測的內容也比較詳細，我覺得這一點是非常方便的，yii最低使用php5.1.0，Tp最低5.0。在開發中我使用是一般都是5.3所以兩者對我都沒有什麼區別。

Yii是純面向物件的框架，而TP提供了一系列單字母函式，相比之下我還是比較更喜歡yii，因為可以避免專案之間的衝突。

衝突例子{

TP在以前的版本【Base基類中】，當時就和一個整合Ucenter時的類衝突了，一度很苦惱。現在TP的各種基類 仍舊是直接命名，如Think 類。在專案開發過程中就會體會命名衝突的痛苦之處。Yii則在框架的類都加上了C 字首（介面是I字首），有效地避免了這個問題。Yii中的 CComponent是所有類的基類，可以看看CComponent 的程式碼，很有用。

說到命名問題了，就不得不說自動匯入的問題。TP的類匯入和Yii的程式碼風格差不多。但是Yii還支援PHP的命 名空間和自定義autoload方法。

}

對比：

TP有個特色叫專案編譯。我覺得與其使用專案編譯，還不如使用APC。在Yii中也有個yiilite.php檔案，裡面就包含了Yii的所有核心類。Yii作者表示在沒有APC的情況下，還是不要使用這個“編譯”好的檔案，因為反而會增加系統開銷。

TP中還在第一次訪問的時候自動生成專案，我覺得這一點和自動編譯一樣，都是我不喜歡的。我對每新增一個if都很敏感，這種判斷讓我很糾結。比如說 TP在每次執行的時候都要檢測PHP版本，而Yii則單獨做了一個內容更詳細的環境監測指令碼。我既然要用這個框架，我在第一次使用的時候，肯定就知道能不 能在當前環境上使用了，為什麼要每次都要檢測呢。當時我就說過，TP為使用者做了太多事情。比如舊版本中的TopN函式。

Yii的元件思路是非常不錯的，用起來十分地舒服。從session到cache，你可以無縫地更換所有的元件而無需重構專案。而且Yii的延遲加 載也做得比較徹底，每個元件都是用到的時候才載入。比如，TP中，如果配置了session自動開啟，則TP在應用初始化的時候執行 session_start()。而Yii則是你用到session的時候才打開session。

說到專案的配置檔案，TP要求是config.php，而Yii則比較靈活，支援多配置檔案。

當初TP很推崇自己的ThinkAjax，現在也改用JQuery。這一點是進步。

TP的

動態模型

可以實現不需要定義Model。但是在實際的專案中，我更傾向於使用Yii的方式。順便說一句，將label定義在model中，為我的日常開發帶來了許多方便之處。

剛才提到TP的專案自動生成，Yii中也有這種工具。而且比起TP，Yii的工具更加強大而且可擴充套件。

從TP的程式碼中，有人可以看出其作者熟悉JAVA。而從Yii的程式碼中，有人會發現其作者熟悉.Net。這常常是我身邊人看到程式碼的時候發生的小插曲。

Yii封裝了大量的頁面控制元件和類庫，也是Yii如此吸引我的一點。這是TP短期無法比擬的，在TP的使用過程中總遇到這樣那樣的問題，讓我感覺TP對我反而是阻礙。而Yii真的是，舒服，實在是太好用了！

無論從程式碼規範、設計思路、類庫豐富程度上來說，TP都遠遠不及Yii。有人說你看TP多簡潔，Yii太臃腫了。錯了！簡單和簡潔不是一回事。TP 那叫簡單，你讀讀Yii的程式碼吧，那才叫簡潔。至於臃腫，去看看Zend Framework就知道了。（順便說一句，我很喜歡Zend Framework，它是學習設計的典範）

Yii封裝了大量的頁面控制元件和類庫，也是Yii如此吸引我的一點。這是TP短期無法比擬的，在TP的使用過程中總遇到這樣那樣的問題，讓我感覺TP對我反而是阻礙。而Yii真的是，舒服，實在是太好用了！

無論從程式碼規範、設計思路、類庫豐富程度上來說，TP都遠遠不及Yii。有人說你看TP多簡潔，Yii太臃腫了。錯了！簡單和簡潔不是一回事。TP 那叫簡單，你讀讀Yii的程式碼吧，那才叫簡潔。至於臃腫，去看看Zend Framework就知道了。（順便說一句，我很喜歡Zend Framework，它是學習設計的典範）

說到讀程式碼。對於程式設計師真的很難嗎？讀寫得好的程式碼應該是一種享受才對。Yii的學習曲線是比TP高那麼一點點，但是對比Yii的巨大優勢而言不算什麼了。而且，我認為在遇到學習困難就退縮或者認為Yii就像天書一樣的人，還是轉行吧。

以上是應一篇評論所寫的。對比TP1，現在的TP2的確有了很多進步，但是還是存在一些問題。對比Yii……，TP真的沒有可比的能力。抱歉讓TP的fans失望了。

那就下定論了嗎？不，不是的。從類庫到框架，再到解決方案。什麼是最好的？每一個人都有不同發說法，這是因為每一個人的思維習慣不同，遇到的問題不同，問題所在的環境也不同。怎麼能奢求所有人都有同一個選擇呢？

還是那句，適合，就是最好的。對我來說，Yii是最好的。

Yii框架與CI框架比較

Yii

1.模型使用起來比較方便。模型是資料的聚合。對資料進行操作的聚合，業務邏輯的封裝。更重要的是模型之間的導航。yii主要定義了四種導航。 has_one belong _to has _many many_to_many 還有另外一個是 stat。通過has_one 可以實現模型的繼承。

2.在mvc架構裡，有c，有v但是在django裡面我卻發現只有m和v和t（template），發現這點並不意外，以為我在編寫yii程式碼的 時候發現c和v之間難以權衡，有些東西我情願寫在v裡面，有些東西我情願寫在c裡面，為的當然是方便，快捷。從複用性來講，是尚失了複用性但卻得到了更大 的靈活和便捷。

3.chtml靜態類。推薦大家能儘量使用chtml靜態類。能幫我們減少不少時間。chtml:button('提交') 這樣子就是一個按鈕了 從程式碼量上面比單純的html減少了，更重要的是能讓我們關注我們需要的部分。chtml::ajaxbutton chtml::link 等等靜態方法，都是常用的。 還有一個東西叫做cactiveform，能夠根據模型來自動配置表單。並且根據驗證規則來自動驗證。我也是我所喜歡的。因為不用重複的在寫驗證規則了。 有些人說這些驗證是服務端的驗證，有沒有客戶端的驗證？有的 jsformvalite就是這樣的一個extension。

**** 對MODEL層的指導和考慮較少。文件例項較少

Yii高效能的PHP框架，用於大規模Web應用，Yii採用嚴格的OOP編寫，從MVC，DAO，ActiveRecord，widgets，caching，等級式，RBAC，web服務，到主體化。提供了今日2.0應用開發所需要的幾乎一切功能。

優點

純OOP

模型使用方便

開發速度快，執行速度也快。效能優異且功能豐富

使用命令列工具。

缺點：

對Model層的指導和考慮較少

文件例項較少

英文太多

要求PHP技術精通，OOP程式設計要熟練！

View並不是理想view，理想中的view可能只是html程式碼，不會涉及PHP程式碼。

【關於CodeIgniter】

優點：

Code Igniter推崇“簡單就是美”這一原則。沒有花哨的設計模式、沒有華麗的物件結構，一切都是那麼簡單。幾行程式碼就能開始執行，再加幾行程式碼就可以進行輸出。可謂是“大道至簡”的典範。 配置簡單，全部的配置使用PHP指令碼來配置，執行效率高；具有基本的路由功能，能夠進行一定程度的路由；具有初步的Layout功能，能夠製作一定程度的介面外觀；資料庫層封裝的不錯，具有基本的MVC功能. 快速簡潔，程式碼不多，執行效能高，框架簡單，容易上手，學習成本低，文件詳細；自帶了很多簡單好用的library，框架適合小型應用.

缺點：

本身的實現不太理想。內部結構過於混亂，雖然簡單易用，但缺乏擴充套件能力。 把Model層簡單的理解為資料庫操作. 框架略顯簡單，只能夠滿足小型應用，略微不太能夠滿足中型應用需要.

評價：

總體來說，拿CodeIgniter來完成簡單快速的應用還是值得，同時能夠構造一定程度的layout，便於模板的複用，資料操作層來說封裝的不錯，並且CodeIgniter沒有使用很多太複雜的設計模式，執行效能和程式碼可讀性上都不錯。至於附加的library 也還不錯，簡潔高效。

細節整理

資料庫驅動部分的缺陷。

CodeIgniter採用的是動態繼承，從而實現了對多資料庫的支援。這種方式可以說，比工廠方式要先進得多。

但是，我認為，CodeIgniter的動態繼承用反了！

試想一下，如果把驅動作為父類，而CI_DB_driver作為子類，結果會如何？

那麼，CI_DB_driver中就可以重寫資料庫查詢，重寫獲取記錄，那可就可以實現對資料CACHE的自動管理與使用。

可是現在，要使用CACHE卻只有父類中的query函式，CodeIgniter在幫助中說明，CACHE不支援num_row,不支援num_fields，這不得不說是一大敗筆！

二、對某些LIBARAY類的看法。

優秀程式碼本身目的是易於維護，易於擴充套件，但是CodeIgniter中的一些類，實在不敢恭維，現舉兩個例子。

第一是圖象處理類，其中使用了三套圖象驅動，但卻將這三套的程式碼寫在一個類中。第二是EMAIL類，做法與是這樣。

試想，假如使用者只用gd，單憑這一點，使用者就需要載入所有的程式碼，資源開銷不論，如果確有意外，要修改，或確有需求要改進，那麼，只需要GD的，同樣還需要對其它驅動的程式碼一一過目。這是快速開發，還是浪費使用者時間？

試想，一個程式碼行如此多的類，是易於維護，還是難以維護？

三、再談資料庫的cache

資料庫的cache，在更新查詢後，刪除所有的cache檔案，這表面上看是沒有問題，但是，讀取檔案時是加鎖的。也正因為這一點，檔案可能刪除不了。然而，cache卻沒有設定有效期，這就導致了前端顯示的資料可能不真實的問題。假如添加了有效期，在讀取時，如果發現過期，則立即刪除，這樣，就是刪除不了，那也不讀取，這樣，也是從資料中查詢的新的。這就維護了資料的真實性。可惜的是，CI並沒有考慮到這一點。

四、資料庫類的擴充套件

懂一點設計模式的人都清楚，動態繼承的類不再可以通過繼承來進一步擴充套件。CI給使用者提供了一個名為 call_function 函式，讓使用者擴充套件。

這種做法，對於初學者而言，或許可以大受歡迎。

但是，這種做法，實際上有很多不雅之處。

第一，擴充套件函式寫在哪裡？勢必寫在全域性的helper函式中。

第二，擴充套件函式如何與資料庫類互動？勢必要在引數中把當前例項傳入。

這種破壞封裝的方式，還不如在文件中加上一個擴充套件例項，新建一個db_ext的類，代理DB類，同時，加上擴充套件函式。這樣在使用時，就沒有必要再弄什麼函式名與DB物件做為引數了。

這種做法，不僅維護了程式良好的結構。同時，也提升了使用者的水平。但CI並沒有這樣做，使用這一函式的目的，或許可能是為了迎合初學者吧。但，KOHANA更注重這些，所以，HELPER函式也放到靜態類中。這一點CI是值得借鑑的。

五、關於base類

CI的base類針對不同的PHP版本寫出不同的程式碼。其實，網上到處都是PHP4與PHP5中均能執行的單件模式程式碼。同時，還有更讓人不解的，既然BASE例項可以用getinstance得到，為什麼還要放到全域性中。這種做法，實在讓人難以相信，CI程式碼竟究有多大的可信度（如同cache一樣，高要求時，資料一定會不真實的。）。縱有一萬個理由，既然單個模式有版本相容的程式碼，那麼，就應當用上。但是，CI沒有這麼做。這在某種程度上大大影響了CI的形象。

六、助手函式

CI實質上並沒有提供實用的助手函式。比如，美其名為檔名助手，但實際上根本沒有什麼函式可用，因為，針對檔案目錄操作的建立，刪除，重新命名，移動，列出清單這五大操作，檔案是五個，目錄也是五個，至少是10個函式，這在CI中，是沒有提供的。

但若你要仔細檢視一下這些助手函式，就會發現，這些函式實際不是提供給使用者用的。是CI本身就用到的。

同時，這些助手函式的程式碼演算法仍不敢恭維。比如，求某年某月共有多少天，這麼一個小小的問題，原本一行程式碼就能算出的，CI中卻用了很多行程式碼，並且用上了曆法知識。而現成的PHP函式放著卻不會用。