進度條

PHP的框架這麼多種該學哪個?來試試看市佔率最高、最熱門的 Laravel 吧!

在PHP中最熱門的「框架」Laravel 是有什麼魔力?

作者: 進度條編輯群 更新日期:

在先前的文章中小編有提到,這世界上30%以上的網站,都是使用 WordPress 架構出來的。但是如果範圍為所有 PHP 網站的話,這個數字會到75%以上。
( WordPress 是用 PHP 寫出來的。)
 

 

(資料來源W3Techs.com, 2020/04/29)

 


延伸閱讀:
1. PHP將死? 或許市場跟你想的不一樣。
2. 任何人都可以辦得到的網路架站,你知道什麼是WordPress嗎?

 

如果對此議題有興趣,也可以參考我們的課程:
Laravel 後端PHP架站,API Server與訂閱軟體全攻略

 

design-desk-display-eyewear-313690.jpg

 

 

當然,市佔率高並不代表它是最好的程式語言,通常是表示它是最容易入門的程式語言之一。畢竟使用的人多,資源也多,工作機會"應該"也多。不過相反的入門薪資可能不高,畢竟物以稀為貴。

 

基本上沒有所謂的最好的程式語言,但是大概可以依據情境而選出幾種最好的解決方案。

 
  

PHP之所以好入門的原因基本上就是因為它環境設定上面很簡單,尤其是跟Apache / Httpd 有著強烈的關係。基本上PHP + Apache下載完,最簡易的網站就可以跑起來了,不用額外設定。如果是在自己電腦的本地端開發的話,套裝的 _AMP 系列也相當的完善,點點滑鼠就好了,不需要打開終端機。

 

_AMP 指的是 MAMP / XAMPP / WAMP 之類的組合產品,幫你把 PHP / Apache / MySQL(MariaDB) 組合起來,只要下載安裝檔安裝即可無痛使用這些程式。解除安裝也非常方便,因為他的設定檔與產生的檔案只會產生在安裝後的資料夾內部,所以只要用官方的解除方式或是刪掉該資料夾即可全部刪除。如果是自己一個一個裝的話,設定檔有可能會散佈在不同的使用者資料夾與系統設定檔內,導致部分系統參數可能被覆寫。

(常見的原因之一為安裝多種版本的PHP或MySQL,結果不知道自己真正被運行到的是哪一個版本的設定檔)
  
_AMP系列則可以避免這個問題,簡單的安裝不容易影響與被影響的開發環境。但也不是沒有缺點,其中之一是_AMP系列不見得會包含最新的版本,也不見得會提出明確的釋出時間。另外一點則是PHP與Apache有很多延伸的函式庫,用_AMP系列則無法直接使用函式庫官方教學的方式安裝,需要額外連結,一般官方的教學都是教連上官方版本路徑的PHP或是Apache。但是如果只是基礎PHP練習或是WordPress開發,使用_AMP系列即可。本文主題的Laravel則不太合適
    
  
_AMP系列的第一個字早期是指作業系統,例如M 指的是MacOS,W指的是Windows。但是其實這樣的產品命名方式有點先搶先贏的概念。所以以MAMP為例,他同時有包含MacOS版本與Windows版本,也都相當穩定。(MAMP Windows 4.1版本的PHP 7.3有問題,需要降版到PHP 7.2才可以使用,詳情可見下面文章。)


延伸閱讀:

[PHP][Mac] 00. 覺得開發環境設定很麻煩嗎,用MAMP安裝就對了!

[PHP][Windows] 00. 覺得開發環境設定很麻煩嗎,用MAMP安裝就對了!

PHP 基礎教學 系列文章
 

 

 

儘管PHP有著入行門檻低、設定方便等優勢,但是現在的網站功能需求越來越複雜,對於初學者來說要自己生出這些功能門檻還是非常高。

 

但有幸於「軟體工程」特性,業主通常都是別人有我也要有,雖然打造功能的過程不是很容易,不過複製或是模組化是相對容易很多的事情。因此有經驗的工程師多半不會一直重複製作功能,也就是所謂的「重造輪子」,而是用以前做好的去修改。其中不乏是好心人的程式高手,分享出自己製作的元件與函式庫。當分享的功能規模大到涵蓋一定程度而且也包含很多自訂的設定邏輯時,即可廣義地稱之為Framework(中文可翻為「框架」,可參考WIKI上的定義) 。

 

主流的程式語言多半都會有流行的框架,不過如果提到網路應用框架的話,光是PHP就有相當多的框架可以使用。畢竟PHP就是為了網路應用而生的程式語言。

 

 

「PHP就是為了網路應用而生的程式語言」這句話可參考PHP原始作者 Rasmus Lerdorf 2018年的演講

節錄幾句話:
注意:這些話是他在談論過去1994年前後,一開始對於PHP的期許,並不是針對現在的發展。

The whole point of the PHP to me was to separate the business logic and the display logic. (3:55)
PHP (過去) 對我來說的重點是區分商業邏輯與顯示邏輯。

This was basically a C API for the web. (4:39)
(過去) 這基本上是網路用的C語言的API。

PHP was a templating system and an API.  (6:58)
PHP (過去) 只是一個樣板系統與API。

But eventually, I gave up, and said: Ok fine, I'll give in and I'll try to make the templating system better so you can acutally write your business login in the templating system.
但是最終我還是放棄了,說道:好吧,我將投入並且讓這個樣板系統更好一些,讓你們可以在裡面寫入商業邏輯。 (7:03)

And people start writing the templating systems for the templating system.
之後大家卻開始為這個樣板系統寫樣板系統。(7:13)


 


補充一下樣板系統,一般寫程式為了模組化,會切割程式架構,讓不同功用的程式不會參雜在一起。現在最有名的就是MVC架構。其中關於畫面通常我們會稱之為template樣板,整個template系統我們就會稱之為templating 系統,以Laravel來說的話就是預設的Blade。


Rasmus Lerdorf 因為一開始製作PHP的用途是為了切割C語言的商業邏輯與外觀,所以PHP本身在一開始是等於Laravel Blade的概念。但是因為C語言寫起來比較複雜,很多都要自己建立,HTML一開始純文字居多。所以很多人要求Rasmus Lerdorf加上一般程式語言常見的Loop與變數的進階功能,讓大家可以直接寫商業邏輯。


但是加上去後,商業邏輯與顯示邏輯就又混成一團了,所以當時的其他PHP開發者就為了解決這個問題寫了PHP用的樣板系統,但對於Rasmus Lerdorf 來說 PHP 的原意就是個樣板系統,因此覺得很無奈。
 

 

 

 


以 PHP 來說的話,比較多人討論的框架有
1. Laravel
2. Symfony
3. CodeIgniter
x. WordPress => 雖然可以像框架一般玩,但一般列為內容管理系統 = CMS 

 

如果以寫文章的當下比較,在Google Trends上無論是台灣或是全球Laravel可以看得出來相對熱門很多,CodeIgniter則在台灣Symfony熱門一些。
(Google Trends 會受到同名不同意思的搜尋影響,但是這三個名稱基本上沒有其他熱門意思)

 


 

補上包含WordPress的圖,雖然WordPress不太像其他三個一樣適合從零開始架構,而且WordPress也包含非程式的應用,是比較不公平一點。

 

 

 

不過如果是新手的話,通常會碰到一個問題:用框架與不用框架有什麼差別。為何我工程師的朋友(或網路上的高手)叫我在新手的階段先不要學習框架?


 

一般來說這意見其實有點分歧。先說用框架的好處,前面有提到現在的功能越來越複雜,用框架與不用框架可能開發時程可以差10倍,而且熱門框架本身被相當多人研究過,所以雖然不是完全沒有安全性風險,但是至少最基本的新手常犯的錯誤都直接有解法。例如不要用明碼儲存密碼、加鹽、API的驗證機制控管,SQL injection的避免,與JavaScript函式庫的互動等。框架都幫你設定好了,基本上你只要照著做即可。以新手階段來說強度會比自己寫要強非常多,畢竟框架本身就代表大量的程式碼。最簡單的想法就是如果把你寫的程式碼跟框架本身的程式碼一起算比例的話,你寫的可能只有1/10之一不到。

 


但是不使用框架有什麼好處呢?這就要從新手只會使用框架對團隊可能造成的困擾來說了。如果完全不懂輪子怎麼造的話,就有可能不知道「輪胎」跟「輪框」其實可以分開的。也不知道輪框需要裝在車子上才能發動。甚至不知道汽車其實需要汽油,不是鑰匙插上就可以發動的。所以比較理想的情況是,技工在修車改車之前,先完整的拆裝至少一種車,拆裝的越細,通常了解的可以越多。畢竟我們在討論的是工程師,而不是使用者,所以不能只會開車而已。

  

  
但是想也知道,是你你願意讓新人學生修車員拆了你的車再裝回去嗎?所以大多時候在職場是沒有這個機會的,有時候因為缺人或是老闆預算的關係,所以學生(新人)直接上戰場不算少見。但這時候無奈的前輩或是小組長只能跟你說照著說明做就好,用框架就有基本的說明,至少不會太差。大家都照著標準做事的話,不用多說什麼就可以有基本的了解。當然這是理論上,畢竟不看說明書的人很多。而且不能發揮創意的話,對工程師來說也是滿痛苦的一件事。儘管如此,使用適合框架還是可以讓大家相對輕鬆很多。

 

如果更口語化一點,使用框架就像辦活動不用每次都自己搭建舞台,而是把搭建舞台的工作交給專門的舞台及音響公司,而活動公司只要專注在活動面上的執行、聯繫與辦理就好,框架基本上就扮演這樣的角色。

 

 

man-in-white-shirt-using-macbook-pro-52608 (1).jpg

 

 

不過前面有偷渡「適合的框架」這幾個字,不曉得大家有沒有發現。這其實還滿重要的。框架本身有規則的概念,也就是說雖然程式語言本身可以符合各式奔放的寫法,但是因為建構在框架上面,所以很多寫法可能都會被視為「不適當」的寫法。如果框架更嚴格一些,甚至會限制應用程式或是資料庫的架構,在API上面去避免一些寫法。所以很多高手越寫越回去,很多功能都不依靠框架實現,就是因為不想被框架的「通用型」功能給侷限。

 

 

不過無論是怎樣的情況,最優先的前提還是要先了解框架本身提供的功能與設計的理念。所以講了這麼多,我們終於要開始介紹本文的主題Laravel提供給我們什麼功能與適合使用在怎樣的情境了。

 

 

 

 

Laravel是一個基於MVC架構的Framework,為Taylor Otwell所建立的免费開源PHP Web 框架,License為MIT,Github可是超過了5萬顆星的好評,不過它並不是從零開始建立起的,Laravel 底層包含非常多 Symfony 的元件,所以可以說 Laravel 在一開始是使用 Symfony 改出來的也不為過(Symfony 官網是這樣說的)。

 

但是如果抱著我會 Laravel 的心態去學習 Symfony 或是反過來學習是一定會覺得很卡的,因為兩個的設計理念其實很不一樣,小編認為 Symfony 是不需要就不裝、「追求」絕對正確型的框架(正不正確則見仁見智)。而相對於Symfony,Laravel 對於開發者則友善滿多的。



以下就先列幾點我們覺得Laravel的特點供各位參考

 

 

程式語法清晰

Laravel 的中心思想就是它的標語「The PHP Framework for Web Artisans」,為網頁藝術家創造的 PHP 框架。所以很多時候他選擇設計對工程師友善的開發方式與API,而非追求絕對學術正確或是極限效能的語法。所以在開發上面對於人類工程師相當的友善。
(這個概念現在非常盛行,尤其是在工程師的成本遠貴於維運機械成本的現在,省下開發維護成本是非常重要的。)

 

 

文檔一致性

雖然Laravel屬開源, 但其框架因有詳細的說明文檔,所以新開發人員不必從新經歷辛苦的學歷過程,而是可以透過一致的文檔快速了解每個Laravel版本中間的變革與瓜葛。

另外一個重點是,很多框架(不一定是指PHP),因為流行性不夠,所以作者處於半放棄的狀態,或是人手資源不足,導致很多文檔年久失修。畢竟開源作者也是需要養家活口,越大的專案共同作者可能越多。開源也是肉弱強食的世界,有名的大專案才能獲得大公司或是社群個人的贊助。因此目前PHP最熱門的框架 Laravel 是文件最完整的框架之一,而且至少熱潮還沒退去之前都會是這樣不錯的狀態。

 

 

易於學習的View模板引擎

Laravel 提供 PHP 模板引擎 Blade,開發者相當容易上手。使用上與另外一個熱門的 PHP 模板 Twig 差不多好上手。

 

 

與JavaScript穩定結合

即使不是使用 PHP 模板來做開發,當Laravel 成為API server的時候預設可以使用 Vue.js 作為 JavaScript 的視覺框架,也可以用來做單頁面應用程式 Single Page Application 的開發。

當然,以全球開發者整體市佔率來說,目前 React.js會比較高一些。不過畢竟React.js 屬於 Facebook,所以即使 React 現在也是 MIT 授權,對於 Laravel 作者來說,Vue.js 身為個人級別的專案比較沒有疑慮。

 

不過因為需求的關係,所以在 Laravel 上面由 Vue.js 切換到 React.js 也只需要幾個官方支援的指令而已。畢竟 Laravel 也是透過 Webpack 來與 JavaScript 函式庫溝通的,實際上並沒有太多的銜接差異。

 


對 React 和 Webpack 有興趣嗎?歡迎參加我們的課程喔!
ES6,ReactJS與Webpack,前端JavaScript全攻略
 

 

 

Asset 與 CSS 等資源支援度佳

網站開發的時候其實有很多資源最好可以預先的處理,Laravel 這方面都幫你處理好了,你只要按照文件擺到對應的位置和使用對應的PHP API,最後執行指令一切輕鬆搞定。無論是圖片還是Sass檔通通沒問題,詳情可看官方文件

 

 

 

 

好用的用戶認證

別懷疑,哪個Web框架用不到用戶身份認證,Laravel預設就包含身份驗證,使用起來非常的方便,附上說明頁面。(Version如果是Master通常只有英文,可以自行搜尋包含中文說明的版本)

 

 

套件

有好的套件可以帶開發者上天堂,Laravel 基本上是使用 Composer 來管理PHP套件,所以很多功能懶得自己開發的話,可以在網路上找找看有沒有合適的Composer 套件喔!而且因為 Laravel 現在是大宗,所以新的PHP套件多少都會考慮到跟 Laravel 合用的情境。此外,因為 Laravel 還是使用了相當多的 Symfony元件當作底層,所以很多為 Symfony 設計的套件其實也都可以無痛的安裝上 Laravel。至於 JavaScript 套件則是前面提到的 Webpack 與標準的 Node.js 那套 npm 或是 yarn,所以沒有太多的問題。

 

 

資料庫 ORM 系統

Object Relational Mapping = ORM 物件關聯對映,這算是 Laravel 類似框架中最重要的一個組件了。單就 ORM 系統來說最有名好用的就不能不提 Ruby on Rails 了(我們有課程可以參考看看喔!請點我)。

Laravel 的 ORM 系統是 Eloquent ,是一套相當優秀的ORM系統,相當好用。不過他也是常常讓 Laravel 被人與 Rails 比較的主因之一。在語法設計概念上與Rails 的 ORM Active Record 相近,不過使用上面當然不完全一樣,畢竟基底的程式語言不同。不過這個特性也讓很多開發者同時有能力開發兩種系統,可以用類似的手法在兩個框架上實現 ( 至少 Model 層是如此 )。所以如果有時間的話,大家也可以兩種熱門框架都玩玩看。

 

舉個簡單的例子,不曉得大家是否知道這兩段代表語法的意圖呢:

Laravel Eloquent 官網說明其中一段


Rails Active Record 官網說明其中一段:

 

 

自帶測試驅動開發

現在應該沒有熱門框架沒有自帶或是無法用套件管理加入測試了吧!Laravel的測試也是相當的完整。熟悉開發後就可以開始玩玩看喔!(說明頁面)

 

 

內建背景任務程式

Laravel 有包含 Queues (隊列)這個功能可以跟 Cron 合作來做背景執行,當然隊列還有其他玩法,不過先講最簡單的做示意。網路訪問有個最基本的 120 秒 time out 限制,所以過長的運算時間一般來說我們沒辦法直接跑出結果,必須要背景執行後再額外通知下載(例如「年度報表型」功能就很適合)。

或是如果想要定時型的功能,因為應用程式本身不會主動執行,必須被觸發,所以一般來說這功能需要透過「作業系統」或其他「帶有時間概念」的服務觸發才能完成。Laravel 預設已經把這部分串好了,所以只需要照著文件做設定即可開發使用。
 

當然,發送Email類型的功能也很適合坐在此功能上面。例如AWS的SES功能(相關課程)。
 

 

除上述優勢外,Laravel 仍有許多族繁不及備載的優點,如果有興趣的話不妨從 PHP 開始了解喔!畢竟跳脫出 Laravel 的標準功能,你還是需要自己使用 PHP 刻出商業邏輯。

 

 


本篇文章雖然是 Laravel 的介紹文章,但是通常新手一定會有選擇上的困難,所以這邊直接寫說怎麼樣的情境用什麼樣的方式去架站會比較好。
 

以結論來說,如果這個站台的工作量值得超過3個「合格的」工程師半年的工作的薪水的話,用 Laravel 會比較好,要大量的工程師工作這個時間長度代表客製化部分較多,商業邏輯較複雜。如果是低於的話,就取決於 WordPress 和 Laravel 哪個團隊比較熟悉。
 
 
如果評估是1個工程師三個月內可以完成的話,通常用 Laravel 不會比 WordPress 要來的完成度高。因為 WordPress 有很多後端使用者互動的元件其實滿花時間的。而且 WordPress 的後台基本上只要是心智正常的人都可以學會如何使用文章管理系統,不太需要去額外訓練顧客,而且網路資源很多,看看文章影片即可。很多工程師常常忽略掉使用者的訓練成本,尤其是付你錢的管理員這個使用者。
 
 
當然,如果是立志成為「後端」工程師的話 Laravel 會比較好一些,畢竟案子要夠大才會需要額外的人手。
 

最後老闆提醒說一定要一再的的提醒各位觀眾我們同時也有 Laravel 的課程 這件事,不嫌棄的話可以看一下我們的介紹影片喔!順便看一下我們的連結,拜託!
 

 


最後,如果你喜歡我們的文章,別忘了到我們的FB粉絲團按讚喔!!

Small logo

進度條編輯群

進度條編輯團隊