摘要：一個(gè)服務(wù)提供器必須包含至少一種方法。服務(wù)提供器一旦被注冊，就可被用于程序的各個(gè)地方。注意服務(wù)提供器的變量來自類中。啟動(dòng)服務(wù)當(dāng)所有的服務(wù)提供器注冊之后，他們就變成了已啟動(dòng)狀態(tài)。再次提示，把服務(wù)提供器作為一種組織工具來使用。

聲明：本文并非博主原創(chuàng)，而是來自對《Laravel 4 From Apprentice to Artisan》閱讀的翻譯和理解，當(dāng)然也不是原汁原味的翻譯，能保證90%的原汁性，另外因?yàn)槭抢斫夥g，肯定會(huì)有錯(cuò)誤的地方，歡迎指正。

歡迎轉(zhuǎn)載，轉(zhuǎn)載請注明出處，謝謝！

Laravel服務(wù)提供器是往IoC容器中綁定服務(wù)的類。事實(shí)上，框架核心就是由很多這樣的服務(wù)提供器驅(qū)動(dòng)管理著容器中綁定的各種資源。基本上框架中的所有組件都是以這種使用提供器注入資源到容器的方式進(jìn)行注冊的。從項(xiàng)目文件app/config/app.php中的providers數(shù)組中可以瀏覽到當(dāng)前項(xiàng)目使用的提供器列表。

一個(gè)服務(wù)提供器必須包含至少一種方法：register。register方法中實(shí)現(xiàn)了類綁定到容器的邏輯。當(dāng)用戶發(fā)起一個(gè)請求時(shí)，框架啟動(dòng)，配置文件中定義的服務(wù)提供器的register方法會(huì)被執(zhí)行。這在Laravel執(zhí)行生命周期的早期就會(huì)觸發(fā)，所以，當(dāng)你的啟動(dòng)文件、比如start目錄中的文件加載之后，這些服務(wù)啟動(dòng)器就已經(jīng)可用了。

注冊 vs 啟動(dòng)
不要試圖在register方法中使用提供器服務(wù)。他只是為了將對象綁定到容器中來使用的。所有關(guān)于綁定類的后續(xù)操作都應(yīng)在boot方法中完成的。

一些通過Composer安裝的第三方類庫，都是通過服務(wù)提供器進(jìn)行注入的。類庫的安裝說明會(huì)明確的讓你在配置文件中通過向providers數(shù)組方法添加配置來使用他們的服務(wù)。服務(wù)提供器一旦被注冊，就可被用于程序的各個(gè)地方。

類庫服務(wù)提供
不是所有的類庫都需要服務(wù)提供器。實(shí)際上，沒有類庫需要它，服務(wù)提供器的作用通常被用來啟動(dòng)組件并使之馬上能被使用。他其實(shí)就是一個(gè)方便我們啟動(dòng)引導(dǎo)代碼類庫綁定到容器的工具。

在每次請求中，不是所有的列在providers配置數(shù)組中的服務(wù)都會(huì)被實(shí)例化。這對在性能其實(shí)是不利的，特別是當(dāng)他們已經(jīng)被注冊，但是項(xiàng)目中又沒有使用到它，這就是一種浪費(fèi)。比如，QueueServiceProvider服務(wù)，只有在那些利用了隊(duì)列的請求中才會(huì)使用到。

為了在請求中，只實(shí)例化那些必須的服務(wù)，laravel生成了一個(gè)“服務(wù)器清單”并存儲(chǔ)在app/storage/meta目錄中。清單中列出了所有應(yīng)用可能需要用到的服務(wù)，也記錄了容器需要綁定的類庫的名稱。當(dāng)應(yīng)用中需要使用queue服務(wù)時(shí)，Laravel知道如何從清單中加載并實(shí)例化QueueServiceProvider。這種延遲加載服務(wù)的方式，極大的提高了整體的性能。

清單的生成
當(dāng)在providers數(shù)組中添加數(shù)據(jù)時(shí)，Laravel會(huì)在下一次請求時(shí)自動(dòng)重新生成清單。

有時(shí)間的話，還是要好好看看這個(gè)清單的，他對你調(diào)試延遲加載服務(wù)是非常有幫助的。

想使用Laravel構(gòu)建出一個(gè)高擴(kuò)展性良好的應(yīng)用，那么就有必要學(xué)習(xí)并將服務(wù)提供器作為一種組織工具來管理我們的代碼。當(dāng)向IoC容器注入大量類時(shí)，代碼都是雜亂的放到app/start文件中來操作的。我們可以使用服務(wù)提供器注冊服務(wù)的方式來代替上面的方式。

萬物伊始
應(yīng)用所有“啟動(dòng)文件”都存放在app/start目錄下的。在請求達(dá)到應(yīng)用時(shí)，根據(jù)請求類型的不同加載相應(yīng)的“引導(dǎo)”文件。啟動(dòng)文件根據(jù)當(dāng)前環(huán)境在start.php之后被加載。例如：artisan.php只在終端命令行模式下被加載。

如下示例。我們的應(yīng)用可能是在使用Pusher⁴來進(jìn)行向用戶的消息推送。為了將Pusher進(jìn)行解耦，這里須要?jiǎng)?chuàng)建一個(gè)EventPusherInterface接口和一個(gè)PusherEventPuser實(shí)現(xiàn)。當(dāng)需求變更時(shí)，我們就能很容易的改變消息服務(wù)商。

interface EventPusherInterface{
    public function push($message, array $data = array());
}

class PusherEventPusher implements EventPusherInterface{
    public function __construct(PusherSdk $pusher)
    {
        $this->pusher = $pusher;
    }
    public function push($message, array $data = array())
    {
        // Push message via the Pusher SDK...
    }
}

下面，我們創(chuàng)建一個(gè)EventPuserServiceProvider：

use IlluminateSupportServiceProvider;

class EventPusherServiceProvider extends ServiceProvider {
    public function register()
    {
        $this->app->singleton("PusherSdk", function()
        {
            return new PusherSdk("app-key", "secret-key");
        }

        $this->app->singleton("EventPusherInterface", "PusherEventPusher");
    }
}

贊！我們對時(shí)間推送進(jìn)行了清晰的抽象。同時(shí)我們還有一個(gè)不錯(cuò)的地方將服務(wù)注冊綁定到容器中。我們只須要在app/config/app.php的provider數(shù)組中添加EventPusherServiceProvider即可。在接下來的應(yīng)用中，任何控制器和類都能使用這個(gè)注入的服務(wù)。

是否須要單例？
我們總需要合適使用bind和singleton。記住一點(diǎn)，一次請求只用一次用singleton，否則用bind。

注意：服務(wù)提供器的$app變量來自ServiceProvider類中。他是IlluminateFoundationApplication的實(shí)例化對象，繼承自Container類，所以可以上面一樣調(diào)用容器中的各種方法。如果你喜歡App這種門面模式，也可以：

App::singleton("EventPusherInterface", "PusherEventPusher");

當(dāng)然，服務(wù)提供器的功能不止于此，我們也可以注冊云存儲(chǔ)、數(shù)據(jù)庫訪問、自定義模版引擎如Twig等類型的服務(wù)。他就是你應(yīng)用中的引導(dǎo)和管理工具，如此而已。

所以，盡情創(chuàng)建屬于你自己的服務(wù)提供器吧。這不需要你非得發(fā)布個(gè)代碼包，只是個(gè)管理管理工具，來方便應(yīng)用加載各種項(xiàng)目須要的組件。

當(dāng)所有的服務(wù)提供器注冊之后，他們就變成了“已啟動(dòng)”狀態(tài)。每個(gè)提供器中的boot方法都會(huì)觸發(fā)。我們通常會(huì)犯這樣一種錯(cuò)誤，就是在register方法試圖去調(diào)用其他服務(wù)。而此時(shí)并不能保證所有的服務(wù)均已被加載，服務(wù)很可能在當(dāng)前是不可用的，這就會(huì)出現(xiàn)錯(cuò)誤。因此，我們應(yīng)該總是在boot方法中去調(diào)用其他服務(wù)。register方法僅僅是用來將服務(wù)注冊到容器中。

在boot方法中，你可以做任何事情：注冊時(shí)間監(jiān)聽器，加載路由文件，注冊過濾器，以及任何你能想到的東西。再次提示，把服務(wù)提供器作為一種組織工具來使用。也許你希望把一些監(jiān)聽事件組織起來？把他們放到boot方法來實(shí)現(xiàn)就是一個(gè)很好的方法！或者，你也可以引入一個(gè)PHP的“事件”或者“路由”文件：

public function boot()
{
    require_once __DIR__."/events.php";
    require_once __DIR__."/routes.php";
}

現(xiàn)在我們已經(jīng)學(xué)習(xí)了依賴注入和利用服務(wù)提供器來組織項(xiàng)目，我們有了使用Laravel創(chuàng)建可維護(hù)、可測試程序的應(yīng)用架構(gòu)的強(qiáng)大基礎(chǔ)。下面，我們繼續(xù)深入學(xué)習(xí)Laravel本身是如何使用服務(wù)提供器，框架如何在這個(gè)引擎下工作！

別被這些框框束縛了自己
記住，不要老想著只有程序包才能使用服務(wù)提供器。要將他作為我們組織服務(wù)的好工具。

你應(yīng)該已經(jīng)注意到app配置文件中已經(jīng)有很多服務(wù)了。每一個(gè)都會(huì)啟動(dòng)框架核心的各個(gè)部分。比如，MigrationServiceProvider負(fù)責(zé)加載數(shù)據(jù)庫遷移的類庫，以及加載Artisan命令；EventServiceProvider負(fù)責(zé)注冊事件調(diào)度類。一些服務(wù)相對比較負(fù)責(zé)，但都是負(fù)責(zé)啟動(dòng)框架核心的某一部分。

約一約這些服務(wù)們
理解這些核心服務(wù)最好的方法還是去讀下源碼。如果能對這些服務(wù)的源碼，和容器的注入非常熟悉，那么Laravel的工作原理也就會(huì)變的非常明了了。

大部分的服務(wù)都是延遲加載的，并非所有請求都會(huì)調(diào)用他們；然而框架基本的部分像FilesystemServiceProvider和ExceptionServiceProvider還是會(huì)隨請求一起啟動(dòng)的。有些人會(huì)說核心服務(wù)和容器_就是_Laravel。Laravel就是將所有不同的部分組合成一個(gè)單一，內(nèi)聚的整體。這些服務(wù)就是框架這棟大廈的骨架。

再啰嗦一次，想了解Laravel如何工作，還是得看源碼，看看框架如何驅(qū)動(dòng)這些核心服務(wù)。能明白這些服務(wù)如何組織的一塊，這些服務(wù)如何實(shí)現(xiàn)本身的功能。深諳這些之后，也許你也能為Laravel做出自己的貢獻(xiàn)！