在各個不同語言的網頁框架之中
講Laravel參考Rails是比較沒有爭議的事實
如果你先學過Rails，你會在Laravel到處都看見熟悉的影子

事實上，當我在兩三年前為java感到厭煩時
當時的兩個選項是分別就是laravel與rails
而我後來的選擇是後者
選擇的原因也很簡單，既然Laravel是參考Rails而設計
那想必Rails是做對了什麼
既然如此我學原版就好，為什麼要學跟隨者呢？（引戰）
加上對PHP的印象不是太好（一些過去恐怖的傳聞）
所以毅然決然走上了不同的道路。

跟我介紹的幾種語言相比
PHP算是相當老派且傳統的網頁語言
但也因為老且傳統，容易成為新語言成長學習的養分（也就是避開那些傳統的問題）
PHP自己也發現了那些問題，而發展了不少框架
按照特性不同可以分為四類：

• 強調支援PHP版本最廣 : CodeIgniter
• 強調全功能 : Symfony、Laravel
• 強調簡約 : Slim、Lumen
• 強調速度 : Falcon

但考量到社群數量與使用人數
近年來幾乎是Laravel一面倒的佔優勢
畢竟成王敗寇這點在框架上也適用
越多人使用社群越活躍，所以也有更多人送pull request或contribution
所以版本更新頻繁、框架越來越好
大者恆大、小者更小
(離題了)

物件導向

PHP 5以後開始支援物件導向（Object Oriented Programming），讓大型專案更容易維護。但也並不是說網路框架非得要使用物件導向才是比較好或是比較正規，例如後面會介紹到的Elixir就是函式導向程式語言（functional programming）一樣相當優秀。有關物件導向與函式導向之間的比較，或許後面有機會會談到。

MVC

傳統的PHP就是單純用來生成HTML碼的，加上早期的專案並沒有MVC的概念，所以資料、邏輯與視覺的區塊常常混雜在一起，或是一個頁面一個檔案，造成專案管理維護上的困擾。為了解決這樣的問題，有人提出了將專案切分為三個區塊：Modle、View、Controller，可以理解為 model 放資料邏輯，view 放視覺邏輯，而 controller放商業邏輯。但資料邏輯與商業邏輯坦白說很難用一條明確的界線一刀切，更多時候是仰賴經驗與團隊默契。

Artisan & Composer

以Rails工程師的角度來理解：

• Composer 就像是bundler，負責管理套件（Package）與處理套件之間的相依性。套件在3.0的時候叫Bundle，在4.0以後才改名為Package（中文好像不需要改變），對應Ruby的Gem。
• Artisan 則是rails命令列，可以用來產生新的model、view、controller

比方說在laravel想要創建一個user的migration

php artisan migrate:make create_users_table

在rails專案我們會這樣寫

rails g migration create_users_table

ORM & Migration

• Laravel 的 ORM 工具名為 Eloquent，基本上遵循了rails ActiveRecord ORM 風格的資料庫互動。可以省去大量與資料庫互動的時間，直接取用關聯式資料的內容。缺點是久了以後會忘記SQL字串怎麼寫，因為實在是太方便了。
• Migration 我認為是現代專案的重大發明，因為我過去寫java時就深受其苦。也就是資料庫結構（Schema）與程式碼版本不一致，而這常常會導致pull或merge最新的版本以後，因為欄位的差異出錯，這完全是沒有必要而且可以避免的。另一個好處是架空了如何實作資料庫異動的程式碼，讓更換不同資料庫這件事變得容易許多（雖然理論上專案並不會常常更換資料庫）。使用migration以後，資料庫的異動就可以被版本控制追蹤，更換不同資料庫時也會自動切換不同的實作語言，對開發者而言相當的方便。

Blade

類似Rails的erb，可以使用php code動態產生html等前端程式碼，但是又盡力不讓前端顯得雜亂。可以繼承、複寫、擴充等彈性組合頁面元件，增加前端的可維護性。

參考資料：
http://oomusou.io/laravel/laravel-for-newbie/
https://www.slideshare.net/shengyou/laravel-43453376