聽說laravel挺火，就用看了一下，沒有深入去看，算是只看完快速入門，看了以後有點失去興趣了，特來知乎請教一下。如果這東西都是用composer的方式調入各種第三方的包來完成任務，那麼靈活性是不是太低了一點，雖然沒有重複造輪子，但是最後大家弄出來都是一樣的輪子，還有安全性好保證麼，聽說效率也不高啊。如果不使用第三方包的情況下，能加快多少開發速度呢？會不會反倒不如其他的架構？
追加：有些回答覺得我對laravel不夠深入所以評價不客觀，ok，我想這也是有可能的，雖然第一感官不好了，但為了不武斷作出結論，我決定繼續深入下去，如果不好，到時候再回來反駁你們，哼哼，=P。
回複內容：
子之武城，聞弦歌之聲。夫子莞爾而笑，曰：「割雞焉用牛刀」。 --- 《論語》
我們學習一個架構，不是因為他簡單易學，而是因為他高效強大。
Laravel 架構的出現，將 PHP 的後端開發帶入了一個新的高度，其中的 composer 和 PHP-FIG 等，標誌著 PHP 已經不再僅僅是“前端語言”、“展示層語言”了。
PHP 的特點就是易於入門，而且 PHP 是一個文法大雜碎，彙集了 C Perl 等等，當年我學了半天時間，就可以拿來做網站了。
對於架構，大部分 PHPer 會首選 ThinkPHP 或者 CI。因為這幾個架構的門檻和 PHP 的門檻很對口。如果像 Java 那樣，學習半年才能做開發，大部分的 PHPer 是接受不了的。如果一個架構（比如 SSH）需要學習半個月才能上手，PHPer 們也接受不了，於是 TP 和 CI 架構大行其道。（PHP 界和 SSH 架構媲美的 ZF 也被 PHPer 鄙視為大而無用，處處透漏這 Java 的臭毛病）
隨著 Laravel 的出現，我毫不猶豫的從 CI 轉入了 Laravel 陣營。
如果你僅僅是為客戶
寫一個網站，那麼即使原生的 PHP 也可以應付，如果想再提高點兒效率，可以選用 TP 或者 CI。
但是，如果你是為公司或者自己開發一個項目，這個項目準備運營五年以上，那麼 CI 的弊端就凸現了。五年間，CI 估計都已經升級了 N 版了，PHP 也升級了 N 版了。你升級嗎？
項目是在本地開發調試完成，當上線後遇到問題了，我們如何尋找，如何跟蹤呢？最通常的辦法就是 log。現在幾乎每個架構都有 log 功能，但是 Laravel 的又一強大之處就是他的 log 遵循 PHP-FIG，也就是以後你可以隨意更換 log 的實作類別以提高效能。這就好比我們的 PC，它上面都有 USB
介面，這樣我們就可以任意更換 USB 裝置，比如 USB 滑鼠，USB 鍵盤，USB 硬碟等。而 Laravel 依據 PHP-FIG 標準提供日誌介面，我們只需要更換實現。
那麼現在問題來了，挖掘機……，現在很多 PC 支援了 USB 3.0，這時，我們買硬碟的時候就可以買支援 3.0 的，以達到更高的速度。Laravel 使用 composer 管理
包依賴。
如果這東西都是用composer的方式調入各種第三方的包來完成任務，那麼靈活性是不是太低了一點
使用 composer 不是為了
調入，而是為了管理，
管理組件，以及各種包的版本。這樣就解決了各種包的相容問題。而在 composer 出現之前，PHP 依然沒有有效方法解決這些問題。如果我們需要一個 Excel 的匯入匯出功能時，就去搜尋 PHP 的 Excel 庫，大部分情況是去官網下載最新的穩定版本。如果出現問題了，就去Google或者百度搜尋，“我去~原來是版本問題，這個庫使用了匿名函數，PHP 5.3 不支援，哎，只能下載以前的版本了~~”。
Composer 將工程化的思想帶入了 PHP。
如果不使用第三方包的情況下，能加快多少開發速度呢？
如果僅僅是
開發速度，Laravel 無疑是低效的，笨重的。這顯然和“世界上最好的語言”不相搭配。但是如果你開發過大中型項目就會發現，編碼（Coding）其實在整個項目階段，連三分之一都占不到。再退一萬步講，開發週期也許是3個月，但是整個項目的生命週期確實3年啊。
如果你的行程是10公裡，那麼無疑開車是最快的，如果坐飛機的，估計還沒有來得及起飛呢。如果行程是100米呢，走路無疑是最快的。
再說說另一個被 PHPer 忽略的問題，那就是單元測試。同樣是 MVC 架構，但是 PHPer 很多是為了 MVC 而 MVC，為了設計模式而設計模式。知其然而不知其所以然。如果問一個 PHPer 為什麼使用 MVC，為什麼使用模式，估計大部分都答不出來。
今天下午還在 sf 看到一個類似的提問，大意是 ThinkPHP 的模型有什麼用，這些代碼完全可以寫在控制器裡面，這樣速度還快。誠然，大部分 PHPer 不知道為什麼要分層架構，即使使用了架構。
談到分層，任何一個 java 架構都可以甩 PHP 幾條街。（PS：從我的名字可以看出，我是java粉，但我也堅信 PHP 是世界上最好的語言）
現在有一個控制器，處理轉賬。在這個流程中，需要表單驗證、控制器處理商務邏輯、持久化（儲存到資料庫）、渲染視圖，還有一些安全處理、日誌功能等。
在傳統的 PHP 開發過程中，都是：編碼，運行，調試改錯，直到運行成功，然後開啟瀏覽器，輸入資料，點擊執行，看結果，如果正確，再次輸入資料，如果錯誤，修改，調試，再開啟瀏覽器，重複，重複，知道自己滿意為止。
我們也可以使用 PHPUnit，我們把轉賬功能寫到一個（幾個）單獨的類裡面，測試轉賬的核心功能。但是我們要想測試控制器，模型，則還需要一些黑魔法。如果在 SSH 中，就 So Easy 了，任何一個模組都可以單獨拿出來進行單元測試。因為任何一個模組，都可以脫離 SSH 架構而單獨運行。
在 SSH 中，我們可以把控制器拿出來，放到 JUnit 中測試控制器的功能。我們也可以把路由器模組拿出來，測試 URL 路由是否正確。等等。而在 PHP 的 CI 或者 TP 架構中，控制器不可能單獨拿出來進行測試。
而 Laravel 對於 PHP 的工程化的另一個貢獻就是——
可測試性。額。。。額。。。額。。。
PHP好不容易有了composer，你居然說這貨沒用？架構的更多目的是為了項目的可持久性，而不是能有多快的去開發一個項目。。
在這個什麼都要迭代更新的年代，沒有可持續的架構，就是廢的。
你的系統如果有上百個功能，每個功能之間還有一定的依賴，除了包管理，還有什麼好的方式，讓幾百個人的團隊來有序開發？強烈推薦學習laravel，你會發現在學習過程中，你會學習到架構之外的更多知識
1.如何翻牆，因為composer的安裝和使用在牆內的速度是令人髮指的
2.如何翻譯，因為laravel的文檔大部分是英文的，比如laravel5.1是6月發布的，直到今天10月19日，完全漢化的文檔還是沒有。
3.如何撕逼，你要對面用TP的人的不理解，用Yaf的人的鄙視，用Yii的人的試探的目光
4.如何營運，項目上線後，面對效能低下的問題你需要redis memcache opcache php7 hhvm 等等等最佳化效能的方案
以上！首先，我個人挺喜歡laravel的。但是，我覺得沒必要神話 laravel。
慢慢更……嗯。
/**********************************************************************************/
composer
只是為了方便你不用重複造輪子，其本身其實和laravel 一點兒關係也沒有。
laravel只是可以用 composer 而已。 沒有 laravel 你也可以用 composer ，
比如 CI3.0就支援 composer , 甚至你不用架構 也可以用 composer 。
composer的特性 和 laravel的特性 沒關係……
composer 和 laravel 並不會 妨礙 你的項目代碼的 自由度。
難道，當核心業務、核心資料相關的組件出現BUG的時候，
你還非要等 composer 更新版本以後 才能修正BUG嗎？
當然不是的……
難道 laravel裡，你就不能寫 include 來引入檔案， new一個對象了嗎？
當然也不是的……
架構的存在，並沒有縮小你寫代碼的自由度。
而只是提供給你了一個規範：
按照這個規範寫，就可以享受這個規範帶來的好處，
而自然也必然的會受到規範的約束，承受規範的壞處。
/**********************************************************************************/
重複造輪子這個事情，並不是完全無意義的
——哪怕是在工作項目中。
很多時候，可以找到的輪子是不合用的，
這種情況下就必然的需要改造輪子，乃至重做輪子。
這是很正常的事情，沒必要懼怕重複造輪子。
當然、一定要評估使用舊輪子、改造舊輪子、重做新輪子之間的利弊，
權衡利弊之後再做出決定。
/************************************************************************************/
像 @justjavac 說的 LARAVEL的單元測試概念，確實是很好的。
這個確實是LARAVEL非常迷人的地方！！！
不過如果說因為laravel支援 PHP-FIG 或者 JUnit ，我們就要支援它。
確實還是要針對不同的項目來看的……
選擇自己的項目合適的架構，比起死忠一個架構 更有意義。
至於大項目……
現在存在多少 持續5年以上，單一系統維護人員超過100人的PHP項目 ？
我想並不是很多吧？
我接觸到的單一系統很大的項目非常少見，
更多的還是N個小型的子系統共存的項目。
而這樣的項目 如果刨除單元測試等優勢……
LARAVEL有多少優勢嗎？感覺並不是太明顯……
[當然，也可能是我沒有接觸過足夠多的“大中型項目”的原因^_^]
/*****************************************************************************************/
LARAVEL 和 CI 給我的感覺：
CI3.0 像一個工具箱。我可以很方便的從中找出需要的工具，進行使用。通過工具箱裡的工具，我也可以加工出很多方便的小工具來用。
LARAVEL 像一個車床。車床可以製造的工具和製造工具的速度，並非是工具箱可以比擬的。但是想要車床製造出工具箱裡的工具來，需要下的力氣也不是工具箱可以比擬的。感覺你的需求和能力與Laravel提供的價值並不在一個位面上Laravel的設計思想是很先進的，非常適合應用各種開發模式TDD, DDD和BDD，作為一個架構，它為你準備好了一切~~composer簡直就是個php的未來，沒有composer，PHP肯定要走向沒落~~
對於新手來說，上手度不是很高，特別是新推出的Laravel 5， 但是學習價值非常高~~你想知道php行業裡面的最新編程思維，學Laravel吧LaraBase——全棧工程師之家
其實很多事情並不複雜，怕的是複雜的理論內容。很多東西一旦想通也就那麼回事兒。很多人覺得 laravel 這不好那不好、這裡難哪裡難，我只能說，laravel 的確不是一流和優秀的架構。laravel最大的特點和優秀之處就是集合了php比較新的特性，以及各種各樣的設計模式，Ioc容器，依賴注入，等等。因此laravel是一個適合學習的架構，他和其他的架構思想有著極大的不同，這也要求你非常熟練php，基礎紮實。如果你覺得laravel很困難 那麼原因只有一個 你php基礎不夠好。
另外，善於利用命名空間和物件導向的諸多特性，去追尋一些東西，你會發現，原來這一切這麼容易。任何事物存在都有其存在的理由，不能一棒子打死，應該取其長 補其短看了路由和orm部分，和前端backbone之類的結合應該很契合，還是很不錯的，另外composer是個很好東西，關於效率問題，web程式的運行效率從來就不在架構，而在資料庫，架構那一點點消耗根本不會是什麼負擔。
補充一下，之前說架構的消耗忽略不計也是不完全正確的，有個奇葩的，從前用drupal二次開發的時候一個簡單的列表頁面竟然單線程消耗20多M記憶體，原因就是drupal本身的配置太複雜了（不是我的配置複雜，而是系統本身複雜），為了內容配置的最大自由度，什麼變數都往頁面裡塞。去stackoverflow上問了，得到的回答是drupal裡這是正常的。。drupal總的來說也是一個架構，只不過這個架構帶著一個cms系統而已，當然這樣的系統對外是必須一系列最佳化才能用的。。
laravel架構還是蠻不錯的，可以說非常全面，配合phpstorm開發還是很開心的。。
分享兩套教學視頻，自己從http://laracast.com
上一個一個拖下來的，無字幕。。
laravel-whats-new 連結: 百度雲 請輸入提取密碼
密碼: 6cwy
laravel-fundamentals 連結: 百度雲 請輸入提取密碼
密碼: aw2h
還有一個phpstorm使用經驗的分享，如果還用sublime甚至zde的朋友儘快換phpstorm吧，可以說sublime的功能它都有，但還有一些進階ide才有的功能，另外即使是vim的使用者也應該嘗試一下，phpstorm有外掛程式也可以類比vim的操作，並享受其他好處。
how-to-be-awesome-in-phpstorm 連結: 百度雲 請輸入提取密碼
密碼: hgga我觀察到一個現象：通常覺得Laravel難學且無用的開發人員中，只會PHP一門語言，或者說，沒有靜態編譯型語言（如C/C++/Java/Go等）使用經驗的開發人員占絕大多數。
