mvc - Laravel vs CakePHP vs CodeIgniter 的看法（效能，開發效率，負債能力）

最近打算用做一個比較中型的PHP應用，想到用比應用廣泛的MVC架構。
要求

1.支援命名空間2.不支援PHP43.架構、效能更重要4.長期穩定，而不是很快就會被淘汰或者解散的架構

Yii2、symfony2都太龐大，不適合。考慮到了Laravel CakePHP Kohana CI。
先說一下自己對這三款架構的看法

1) CI 2.x    官網一种放棄狀態    CI架構太輕巧，很多東西都要自己做，非常陳舊    CI架構在IDE中無法進行代碼跟蹤，點擊類名無法跳轉過去2) CakePHP 2.x    為什麼非得向下相容PHP4?弄得非得用一個蹩腳的App::use()來替代namespace！    為了相容PHP4弄得整個架構亂七八糟    如果CakePHP放棄對PHP4的相容，應該會有更多的人使用3) Laravel    不支援php4,支援命名空間    網上非常多的好評，仔細看每個評測文章都是複製粘貼的感覺很槍手。

網上包括segmentfault上都有對架構的比較，但基本上是都是摘抄的轉載的，而不是自己使用過後的真實體會，期待有使用過後的真實體會，而不是複製粘貼網上人云亦云的測評。

今天使用Laravel，發現文檔不是官方宣傳的那樣豐富，而是少非常不清晰。Route的所有方法有那些，根本就找不到這些說明。官方的文檔只是幾個簡單的例子，根本就不詳盡。

2015-6-16 補充：
再次回到這個問題，我已經一路使用了CodeIgniter、ThinkPHP 再到Yii2，開發了一些完整的項目。現在發覺 PHP 的 MVC 模式確實難以滿足需求，到後來的 component，現在再到laravel的思路，難以理解，總是一直感覺在追趕，特別疲憊。

其實一開始，我走過太多的彎路，很多年以前，對於OOP都有著強烈的排斥和極端的抵觸，原因就是使用了class 類會導致程式運行非常慢，究其根本是我使用的運行環境實在是太爛了，虛擬機器主機都不如，而且還是win。到後來MVC模式，載入的檔案數目幾乎是無法比擬。後來開始使用MVC架構，普通的主機已經完全無法支撐，絕大部分虛擬機器主機大部分都是win伺服器、而且PHP最多最多PHP5.3就不錯了，還有很大一批居然還在PHP5.0（虛擬機器主機就是只提供一個FTP使用者名稱密碼的那種）。

走過太多的彎路，一直以來總是被硬體條件、運行環境束縛思維。

回複內容：

最近打算用做一個比較中型的PHP應用，想到用比應用廣泛的MVC架構。
要求

1.支援命名空間2.不支援PHP43.架構、效能更重要4.長期穩定，而不是很快就會被淘汰或者解散的架構

Yii2、symfony2都太龐大，不適合。考慮到了Laravel CakePHP Kohana CI。
先說一下自己對這三款架構的看法

1) CI 2.x    官網一种放棄狀態    CI架構太輕巧，很多東西都要自己做，非常陳舊    CI架構在IDE中無法進行代碼跟蹤，點擊類名無法跳轉過去2) CakePHP 2.x    為什麼非得向下相容PHP4?弄得非得用一個蹩腳的App::use()來替代namespace！    為了相容PHP4弄得整個架構亂七八糟    如果CakePHP放棄對PHP4的相容，應該會有更多的人使用3) Laravel    不支援php4,支援命名空間    網上非常多的好評，仔細看每個評測文章都是複製粘貼的感覺很槍手。

網上包括segmentfault上都有對架構的比較，但基本上是都是摘抄的轉載的，而不是自己使用過後的真實體會，期待有使用過後的真實體會，而不是複製粘貼網上人云亦云的測評。

今天使用Laravel，發現文檔不是官方宣傳的那樣豐富，而是少非常不清晰。Route的所有方法有那些，根本就找不到這些說明。官方的文檔只是幾個簡單的例子，根本就不詳盡。

2015-6-16 補充：
再次回到這個問題，我已經一路使用了CodeIgniter、ThinkPHP 再到Yii2，開發了一些完整的項目。現在發覺 PHP 的 MVC 模式確實難以滿足需求，到後來的 component，現在再到laravel的思路，難以理解，總是一直感覺在追趕，特別疲憊。

其實一開始，我走過太多的彎路，很多年以前，對於OOP都有著強烈的排斥和極端的抵觸，原因就是使用了class 類會導致程式運行非常慢，究其根本是我使用的運行環境實在是太爛了，虛擬機器主機都不如，而且還是win。到後來MVC模式，載入的檔案數目幾乎是無法比擬。後來開始使用MVC架構，普通的主機已經完全無法支撐，絕大部分虛擬機器主機大部分都是win伺服器、而且PHP最多最多PHP5.3就不錯了，還有很大一批居然還在PHP5.0（虛擬機器主機就是只提供一個FTP使用者名稱密碼的那種）。

走過太多的彎路，一直以來總是被硬體條件、運行環境束縛思維。

CakePHP沒用過不予置評。

一個php程式員的成長過程往往可以類比成 CI -> Laravel -> CI。CI和Laravel基本可以認為是過去幾年和現在兩個時期的PHP架構霸主，使用率最高的架構。CI適合完全新手和高手，Laravel適合中層級程式員提高生產力。

詳解

CI提供的東西少，恰恰是其立於不敗之地的最重要的原因。

另外，CI的文檔簡直就是開源軟體的典範，非常之清晰、詳盡！

它能給我們最核心的功能，讓我們真正感悟php做web的精髓，感受MVC的真正魅力。BTW，不要小看MVC，它作為現代GUI軟體開發久經考驗的最流行結構，不是在還沒用過MVC時候看兩眼描述就能理解的，我們需要去做，去感受。

Laravel號稱完全模仿Rails，不得不承認他們做到了，包括效能。^_^ Laravel其實是符合互連網產品的開發特點的：迅速做出可用產品，再高速迭代。

如果你用了Laravel，也不用擔心效能問題，因為當出現效能問題的時候，效能也就不是問題了。有使用者有錢有時間，想怎麼重構怎麼重構，妥妥的~

你的分析很多都是錯的.

(1) EllisLab確實曾經想找人接盤CI, 但事實上, github上CI的更新一直沒停過.

(2) cakephp 2.x只支援php 5.x, 並不支援php 4.x, 支援php 4.x的是cakephp 1.x, cakephp 2.x不用命名空間是因為命名空間是php 5.3後才有的, 而原先php社區的計劃是把這些特性放到php 6裡. 僅支援php 5.4的版本是cakephp 3, 馬上要出正式版了. 如果你優先看中長期穩定的話, cakephp肯定是首選, 它到現在還在維護僅支援php 4.x的cakephp 1.x版的bug修正.

(3) 如果你認為yii2和symfony算大的話, Laravel你就不該考慮, 這東西是構建在大量symfony components上的, 不過大小真有那麼重要麼? 現在也並不是10多年前1MB空間1~2RMB的時代了, 不是麼?

7月20日更新：最新的Yii2已經原生支援讀寫分離，支援一個寫資料庫和多個從資料庫。也支援多個寫庫多個從庫！

不贊同題主關於Yii2龐大的說法，Laravel算上他依賴的第三方代碼，比Yii2檔案多的多。況且僅僅從一個檔案多少就來斷定一個架構是否龐大是非常膚淺的。

事實上Yii2本身非常靈活，絕大部分的組件是可被替換掉的。你可以閱讀一下他們最新的文檔，Yii2本身就可以單獨的嵌入到你原有的代碼裡去，你想用AR就載入AR組件(事實上這個功能在Yii1時代就提供了，當初我就在本自有項目裡非常容易的用到了Yii1的model組件，不過由於之前的架構實在過於混亂加上一些其他緣故，最終放棄了該項目)。

Yii2本身功能完善，而且一直在積極吸收其他架構優秀的特性，比如symfony2的AssetBundle、WebDebug都是非常實用的功能。然後是後台神器Gii+GridView這兩個組件，應付大多數後台開發就是簡單的點兩下，改改就OK了，還有DataProvider這個組件也非常實用。總之大部分web開發中要用到的功能Yii都幫你提供了現成的，你只需要用就好了，不好用就繼承一個改改，然後在配置裡將他替換掉就OK了。

然而在提供如此多功能的前提下，Yii2的效能居然不差，我已經有兩個項目是基於Yii2的，其中一個日均pv在300W左右，完全無壓力。很多第三方的測試也顯示Yii架構的效能一直名列前茅(yaf、phalcon這些用C寫的就另算了，CI功能太簡單，我覺得拿他來比較不合適)

當然，Yii2也不是沒有問題，就目前我遇到的一個情況就是某些地方組件的耦合度有點高，比如yii\web\User這個類，他為了最大限度的提升開發效率，跟ActiveRecord耦合的有點高，在web上這當然沒問題，但現在移動開發當道，這個就有點不適合了，需要自己改一些東西。

另外一個就是架構本身缺少資料分層的支援，所有跟資料庫打交道的東西都是ActiveRecord。而由於Yii2提供的ActiveRecord非常易用，很容易就導致濫用，我其中的一個項目就是這樣濫用過，很多類似這樣的代碼$user = User::findOne($uid);直接就寫在了controller裡，醒悟過來後花了不少時間來處理。

當然怨念最深的就是號稱為web2.0而生的架構，居然從1到2都沒有官方支援的讀寫分離功能，這點實在說不過去。

最後Phalcon絕對是神器！http://phalconphp.com

Laravel的核心思想是IoC和Facades，要實現這兩個思想就難免需要大量的抽象類別，一個架構好不好要綜合來看，整體看來Laravel還是非常優雅的，儘管為了實現Facades使用了一些__call魔術方法，但這樣就非常完美的解決了耦合問題，我覺得沒有一定的大型網站開發經驗很難真正的體會解耦的重要性，因此相比效能，業務的耦合度要重要得多，其實代碼本身都不複雜仔細去分析幾個核心檔案你就會豁然開朗，推薦一篇文章，說得很細http://www.yuansir-web.com/?p=1012&preview=true

我個人覺得現在的架構主要分兩種，一種是純MVC的，CI是典型代碼，很多程式員自己寫的架構都是受CI的影響，我個人就是深受CI的影響，因此在自己的項目裡面自己寫的架構基本可以算作是CI的核心剝離，去除了不需要的相容性和國際化的部分，但是經過了一些大型項目之後，我發現現有的MVC已經遠遠不能滿足我對業務的需求，複雜的代碼導致越來越多的MVC三層龐大錯綜，依賴嚴重，很多進行業務拆分的時候發現MC已經完全沒有辦法拆開了，工程量浩大，最後只有把代碼寫得越來越像麵條，越拉越長

最近自己重寫架構的時候我的View類不得不從static轉換為普通類，使用new的方式執行個體化，因為只有這樣我才能在模板中使用$this指向View類，從而在模板裡面調用一些View的功能函數，如request執行個體$this->request()->get('user_id')，擷取$_GET參數user_id，但是如果這樣做我原來代碼裡面View::display('index.php')這樣的調用方式就不行了，在PHP5.5中會有一個警告，說你使用靜態方式調用非靜態類，但是我又不想使用new的方式，一方面不夠優雅，另一方面不夠獨立，如果給在Controller裡面使用View就需要繼承或者執行個體化之後賦值給Controller的一個屬性，這樣就依賴了，我希望Controller是獨立的，在不使用View的時候（很多情況的API開發不需要View）完全都不用引入View類，而這個問題正是Laravel的Facades解決的

Facades允許使用靜態方式調用非靜態累，具體可以看代碼的__callStatic，原理很簡單，儘管這樣犧牲了一些效能，但為了這個優雅性我覺得還是值得的，然後最重要的是IoC和Facades的結合，為什麼Laravel能和使用大量的第三方架構的代碼，完全基於其先進的IoC思想，不用怎麼改動第三方代碼就可以輕鬆的注入到IoC容器中，然後組織綁定到Laravel中，看起來像東拼西湊的，其實核心思想就是這樣的，任何模組都是獨立的，就好像蓋樓一樣，所有的配件都是獨立生產的，然後組合到一起，只有這樣架構的耦合才完美的解決了，因此我現在寫代碼都會寫得特別獨立，不需要用某個功能，直接刪除掉相應的檔案，整個架構不受任何影響，依舊順暢執行

說了很多，其實主要是想說國外很多架構之所以火不是沒有理由的，要學會從中立的角度去看待別人的思想精髓，不能從程式員簡簡單單的測評就一口否定，這也是開源的精髓，集思廣眾

本人項目曆程：原生PHP->CodeIgniter->Yii1->Yii2

2014年07月12日那會，Yii2處於Beta期，Yii官方也不推薦用於生產環境，同時個人也認為還不成熟。

經過一年時間發展，目前截止2015年10月15日，Yii2已經非常成熟了，而且本人目前的項目也是基於Yii2開發的，已運用到生產環境中。

具體開發、修複bug曆程，可以看Github和官網

目前，部分文檔並不健全，比如 Development Tools 模組，指南文檔

swoole如何? http://www.swoole.com/

Laravel 我嘗試過寫一個DEMO，並沒有想象中那麼好用，個人覺得小項目用 CI 足夠，大項止還是用 Symfony2 吧！

我目前覺得yaf+composer挺爽

正在學laravel，比thinkphp和zend framework 2 都爽，光看路由就覺得優雅非凡。

CI 是PHP5.2和5.3時代的架構.

Lavarel 是PHP5.4時代的架構, 文檔不全你是指L3還是L4? 而且大部分文檔都可以在官方論壇裡面文章找到, 文檔就是普通的索引,沒有太多例子很正常, 哪個開源項目不是這樣. L4 文檔還算好的了.
當然中文文檔肯定是跟不上了.

用過larave，除了他代碼寫得十分美好，介面設計得十分漂亮之外，router的效能十分差！

這麼多架構~一個都沒用過。thinkPhp體驗過，yii也體驗過，具體如何，我也不知道

我個人認為Laravel對第三方包依賴太多(特別是Symfony)，給人的感覺就是對Symfony的二次開發

Laravel API文檔也太精簡了吧。精簡得讓你不看源碼都不知道怎麼用。

laravel5.1一個空項目，或者連結資料庫，取一個表的幾條記錄顯示出來：
用 ab -t 10 -c 10 http://127.0.0.1/laravel511/public/index.php
或 ab -n100 -c100 http://127.0.0.1/laravel511/public/index.php
得出的結果 request per time: <50

而如果換slim3 或 ci3 測試，可以達到 reququest per time : 200-300

如果不用任何架構，同樣測試，則可以達到：request per time : 1300

不明白這樣的情況下，還要用架構嗎，項目套上架構性竟然能這麼低啊。

趕腳白瞎了機器硬體啊。

CakePhP，比較穩定，

為什麼不用ThinkPHP呢

