最佳實務系列（一）-- 漫談 PHP 組件、架構、Composer 那些事

1、什麼是組件

組件是一組打包的代碼，是一系列相關的類、介面和Trait，用於協助我們解決PHP應用中某個具體問題。例如，你的PHP應用需要收發HTTP請求，可以使用現成的組件如 guzzle/guzzle 實現。我們使用組件不是為了重新實現已經實現的功能，而是把更多時間花在實現項目的長遠目標上。

優秀的PHP組件具備以下特性：

• 作用單一：專註於解決一個問題，而且使用簡單的介面封裝功能
• 小型：小巧玲瓏，只包含解決某個問題所需的最少代碼
• 合作：PHP組件之間可以良好合作，組合在一起實現大型項目
• 測試良好：本身提供測試，而且有充足的測試覆蓋度
• 文檔完善：應該提供完善的文檔，能讓開發人員輕易安裝、理解和使用

2、組件 vs 架構

我們選擇架構時，要為這個架構的工具投入很多，架構通常會提供大量工具，但卻沒有提供我們所需的某個工具時，痛苦就轉嫁到我們頭上，我們要尋找並整合自訂的PHP庫。把第三方代碼整合到架構中是件難事，因為第三方代碼和架構可能沒有使用相同的介面。

選擇架構時，我們看中的是架構的未來，但是誰又能保證某個架構始終是完成某項工作最好的工具呢？存在多年的大型項目必須有好的表現，而且要時刻做好調整，如果選錯了PHP架構，可能無法做到這一點。較舊的PHP架構可能由於缺乏社區支援而變慢或過時，這些舊架構通常使用過程式代碼編寫，而沒有使用新式的物件導向代碼以及PHP的一些新特性，總之，決定是否使用PHP架構時，要考慮的事情很多。

慶幸的是，Laravel在這些擔憂方面表現良好，因此才能在眾多PHP架構中脫穎而出，從某種意義上來說，Laravel也是個基於組件開發的架構（核心組件是自身的Illuminate庫，功能實現上則大量依賴第三方組件），相比Symfony而言，上手又比較簡單，所以兼具了擴充性和易用性。但是，Laravel也存在一些不足，比如Laravel自身的組件不能輕易解耦，用於Laravel架構之外（但是相信這種狀況會有好轉，比如其資料庫和隊列組件就可以解耦出去）。綜合來看，Laravel仍是一個出色的架構，能幫組我們快速建立強大的應用。

那我們應該使用組件還是架構呢？答案是，使用正確的工具做正確的事，如果能通過一些PHP組件快速實現小型項目，那就使用組件，如果有多個團隊成員開發大型項目，而且能從架構提供的約定準則和結構中受益，那就使用架構（如果是在糾結使用什麼架構，那麼選擇Laravel吧，它不會讓你失望），使用架構能夠引導並加速項目的開發。

PS：這句話也適用於語言之爭，用正確的語言做正確的事，沒事少BB，這是學院君對語言之爭的態度和立場。

3、使用組件

Packagist

我們在 Packagist 中尋找PHP組件，這個網站用於收集PHP組件，最好的PHP組件在Packagist中都能找到。

比如我們想使用一個http組件用於收發HTTP訊息，在搜尋方塊中搜尋http，得到的第一個結果就是Guzzle，就用它吧。

Composer

Packagist是尋找PHP組件的社區，Composer則是安裝PHP組件的工具。Composer是PHP的依賴管理器，運行在命令列中，你告訴Composer需要哪些組件，Composer會下載並把這些組件自動載入到你的項目中，就這麼簡單。

Composer和Packagist緊密合作，如果你告訴Composer想要使用 guzzlehttp/guzzle 組件，Composer會從Packagist中擷取 guzzlehttp/guzzle 組件，找到這個組件的倉庫地址，確定要使用哪個版本，還能找出這個組件的依賴，然後把 guzzlehttp/guzzle 組件及其依賴下載到你的項目中。

此外，Composer會為項目中的所有PHP組件自動產生符合PSR標準的自動載入器，有效地抽象了依賴管理和自動載入，所以，對PHP社區來說，Composer是最重要的附加工具，沒有之一，想想之前我們要使用諸如include、require、spl_autoload_register來手動實現自動載入的痛苦日子，這一點也不為過。

關於Composer的安裝和使用，這裡不贅述，請參考 Composer中文網 。

4、樣本項目

下面我們通過一個樣本項目來示範如何使用Composer和組件來開發一個PHP應用，這個應用的作用是掃描一個CSV檔案中的URL，找出死鏈，該應用會向每個URL發HTTP請求，如果返回的HTTP狀態代碼大於等於400，就把這個死鏈發給標準輸出。這是一個命令列應用，開發好之後，我們會執行這個指令碼，傳入csv檔案的路徑，在標準輸出中顯示死鏈列表。

安裝組件

開始之前，先看看哪些任務可以使用現有的PHP組件解決：我們需要一個可以迭代處理csv檔案資料的組件，此外還要向csv檔案中的每個URL發送HTTP請求，因此還需要一個可以發送HTTP請求並檢查HTTP響應的組件。

瀏覽Packagist後，我們找到 guzzlehttp/guzzle 和 league/csv 兩個組件，前者用於處理HTTP訊息，後者用於處理CSV資料。下面我們在項目最頂層運行如下命令：

composer require guzzlehttp/guzzlecomposer require league/csv

Composer會將依賴安裝到根目錄的 vendor 目錄下，安裝完成後，會在根目錄下產生 composer.json 和 composer.lock 檔案：

composer.lock 檔案中會列出項目使用的所有PHP組件，以及組件的具體版本號碼，這其實是鎖定了項目，讓項目只能使用具體版本的PHP組件。這樣的好處是，composer會下載這個檔案中列出的具體版本，而不管Packagist中可用的最新版本是多少，你應該把 composer.lock 檔案納入版本控制，這樣讓團隊成員使用的PHP版本和你一樣，如果本地開發和伺服器使用的PHP組件版本相同，可以盡量降低由組件版本不同導致的bug。

如果確實要下載最新版本的組件並更新 composer.lock ，可以使用 composer update 命令。

自動載入

接下來我們來編寫應用代碼，在根目錄下建立一個 scan.php 檔案，然後在該檔案頂部使用 require 匯入Composer建立的自動載入器：

    
 Composer建立的自動載入器其實就是個名為 autoload.php 的檔案，儲存在 vendor 目錄中，Composer下載各個PHP組件時，會檢查每個組件的 composer.json 檔案，確定如何載入該組件，得到這個資訊後，Composer會在本地為該組件建立一個符合PSR標準的自動載入器。這樣我們就可以執行個體化項目中的任何PHP組件，這些組件按需自動載入。 
    
 編寫代碼 
    
 下面我們正式使用Guzzle和CSV組件編寫 scan.php 代碼： 
    
get($csvRow[0]);        //檢查HTTP響應的狀態代碼        if($httpResponse->getStatusCode() >= 400) {            throw new Exception();        }    } catch (Exception $e) {            //把死鏈發給標準輸出            echo $csvRow[0] . PHP_EOL;    }}
    
 下面我們在 urls.csv 中添加一些URL，一行一個，而且至少有一個是死鏈： 
    
  
    
 然後開啟終端，執行 scan.php 指令碼： 
    
php scan.php urls.csv
    
 我們傳入了兩個參數，第一個是指令檔 scan.php 的路徑，另一個是CSV檔案的路徑。輸出如下： 
    
  
    
下一節我們將探討私人的PHP組件以及如何建立自己的PHP組件並上傳到Packagist。
