摘要：組件擴(kuò)展通常有兩種方法向容器中綁定自己的接口實現(xiàn)痛過使用工廠模式實現(xiàn)的類注冊自己的擴(kuò)展。類庫管理類以工廠模式實現(xiàn)，負(fù)責(zé)諸如緩存等驅(qū)動的實例化。閉包須要傳入繼承自和容器的實例化對象。當(dāng)完成擴(kuò)展之后要記住中替換成自己的擴(kuò)展名稱。

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

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

Laravel為我們提供了很多自定義系統(tǒng)組件的擴(kuò)展點，你甚至可以完全的替換掉他們。比如，哈希結(jié)構(gòu)是由HasherInterface接口約定的，你可以根據(jù)你的應(yīng)用來實現(xiàn)自己的需求。你也可以擴(kuò)展自己的Request對象，并添加自己的“輔助”方法。甚至我們完全添加自己的認(rèn)證、緩存、SESSION驅(qū)動。

Laravel組件擴(kuò)展通常有兩種方法：向IoC容器中綁定自己的接口實現(xiàn)；痛過使用“工廠模式”實現(xiàn)的Manager類注冊自己的擴(kuò)展。本章將探索多種擴(kuò)展框架的方法，以及必要的測試代碼。

擴(kuò)展方式
牢記Laravel組件擴(kuò)展的兩種方式：IoC容器綁定和使用Manager類注冊。類庫管理類以工廠模式實現(xiàn)，負(fù)責(zé)諸如緩存、session等驅(qū)動的實例化。

Laravel有諸多Manager類庫來管理創(chuàng)建那些基于驅(qū)動的組件。它包括緩存、session、認(rèn)證、隊列組件。管理類的職責(zé)是根據(jù)應(yīng)用的配置來創(chuàng)建特殊的驅(qū)動實例。例如，CacheManager可以創(chuàng)建APC、Memcached、Native、以及其他緩存驅(qū)動系統(tǒng)的實現(xiàn)。

所有這些管理器都有個extend方法，可以輕易的將新的驅(qū)動功能注入到其中。對于上面所有的管理器，我們通過實例來演示如何注入我們自定義的那些服務(wù)驅(qū)動。

學(xué)習(xí)我們自己的管理器
請花一些事件來熟悉下Laravel提供的Manager類庫，如CacheManager、SessionManager。通讀這些代碼可以讓你加深理解。所有的管理器類都繼承自IlluminateSupportManager基類，他為每個具體的管理器提供了很多常見使用的方法。

我們通過在CacheManager類中的extend方法綁定自定義的驅(qū)動解析器來擴(kuò)展Laravel的緩存機制。比如，注冊一個“mongo”驅(qū)動到緩存驅(qū)動中，代碼如下：

Cache::extend("mongo", function($app)
{
    // Return IlluminateCacheRepository instance...
});

傳入method方法的第一個參數(shù)是驅(qū)動名稱。通常和app/config/app.php配置文件中的driver選項匹配。第二個參數(shù)是返回IlluminateCacheRepository實例的閉包。閉包須要傳入繼承自IlluminateFoundationApplication和IoC容器的實例化對象$app。

對于我們自定義的緩存驅(qū)動，要實現(xiàn)IlluminateCacheStoreInterface接口的約定。因此，我們的MongoDB緩存實現(xiàn)代碼為這樣：

class MongoStore implements IlluminateCacheStoreInterface {

    public function get($key) {}
    public function put($key, $value, $minutes) {}
    public function increment($key, $value = 1) {}
    public function decrement($key, $value = 1) {}
    public function forever($key, $value) {}
    public function forget($key) {}
    public function flush() {}

}

我們只需要使用MongoDB連接來實現(xiàn)上述類中的各個方法即可。當(dāng)完成上述實現(xiàn)，就可完成我們自定義的驅(qū)動注冊：

use IlluminateCacheRepository;

Cache::extend("mongo", function($app)
{
    return new Repository(new MongoStore);
}

如上可見，我們可使用IlluminateCacheRepository來直接創(chuàng)建我們自定義的緩存驅(qū)動，而無需創(chuàng)建自己的（Repository）倉庫類。

如果不知道該把代碼放在哪里，可以考慮放到Packagist！或者在應(yīng)用主目錄下創(chuàng)建一個Extensions命名空間的目錄存放。例如你的應(yīng)用起名叫個Snappy，可以把這個擴(kuò)展放到app/Snappy/Extensions/MongoStore.php。Laravel創(chuàng)建的應(yīng)用沒有死板的各種結(jié)構(gòu)的要求，根據(jù)你的喜好自己來組織就好。

何處引入擴(kuò)展
如果你還在考慮該在何處引入擴(kuò)展，不妨繼續(xù)使用服務(wù)提供器。我們已經(jīng)討論過這是組織我們代碼的一個利器，要善用利器。

擴(kuò)展Session機制其實像擴(kuò)展緩存機制一樣簡單。同樣，使用extend方法來注冊我們自己的驅(qū)動：

Session::extend("mongo", function($app)
{
    // Return implementation of SessionHandlerInterface
});

注意，我們自定義的驅(qū)動須要實現(xiàn)SessionHandlerInterface接口。此接口是被包含在PHP5.4+核心中的。如果你在使用PHP5.3，Laravel也是向前兼容的，Laravel已經(jīng)為您定義好此接口。接口中包含了一些我們須要實現(xiàn)的方法。一個基于MongoDB實現(xiàn)的驅(qū)動代碼如下：

class MongoHandler implements SessionHandlerInterface {

    public function open($savePath, $sessionName) {}
    public function close() {}
    public function read($sessionId) {}
    public function write($sessionId, $data) {}
    public function destroy($sessionId) {}
    public function gc($lifetime) {}

}

這些方法不像StoreInterface接口那樣秒懂，讓我們來快速過一遍這些方法：

open方法一般是在基于文件系統(tǒng)的實現(xiàn)中被用到。自從Laravel基于以PHP自身的本地存儲實現(xiàn)了native會話驅(qū)動方式，你基本上不需要在本方法中添加任何東西了。你可以把他留空。PHP這種接口設(shè)計很顯然是一種不好的設(shè)計方式（我們后續(xù)討論）。

close方法同open方法，通常不用理會。大多數(shù)驅(qū)動都不需要他。

read方法返回根據(jù)$sessionId變量關(guān)聯(lián)session數(shù)據(jù)的字符串。這里不需要進(jìn)行序列化或者其他類型的轉(zhuǎn)義，Laravel已經(jīng)幫你進(jìn)行了處理。

write方法根據(jù)$sessionId關(guān)聯(lián)session數(shù)據(jù)將$data數(shù)據(jù)寫入持久化存儲系統(tǒng)中，如MongoDB、Dynamo等。

gc方法將根據(jù)$lifetime指定UNIX時間戳銷毀之前所有的session數(shù)據(jù)。對于可以自動刪除過期數(shù)據(jù)的系統(tǒng)比如Memcached或者Redis，該方法留空即可。

當(dāng)實現(xiàn)SessionHandlerInterface之后，我們就可以向Session管理器中注冊他了：

Session::extend("mongo", function($app)
{
    return new MongoHandler;
});

當(dāng)會話驅(qū)動注冊之后，在配置文件app/config/session.php中指定mongo配置就能使用我們自定義的session驅(qū)動了。

分享你的成果
記住，如果你實現(xiàn)了自己的session驅(qū)動，可以在Packagist上分享給大家！

類似緩存和會話擴(kuò)展，我們繼續(xù)從method方法開始：

Session::extend("mongo", function($app)
{
    return new MongoHandler;
});

接口UserProviderInterface的實現(xiàn)指責(zé)是從各種持久化存儲系統(tǒng)如MySQL、Riak等中獲取數(shù)據(jù)，并返回接口UserInterface實現(xiàn)的對象。這兩個接口可以讓Laravel專注于驗證本身，而無需關(guān)心用戶數(shù)據(jù)的存儲實現(xiàn)，以及用戶對象是那種類來表示的問題。

讓我們先看一下UserProviderInterface接口：

interface UserProviderInterface {

    public function retrieveById($identifier);
    public function retrieveByCredentials(array $credentials);
    public function validateCredentials(UserInterface $user, array $credentials);

}

retrieveById方法通常接收的參數(shù)是一個唯一標(biāo)識符，例如MySQL數(shù)據(jù)庫中的主鍵自增索引ID。該方法將獲取$identifier對應(yīng)的數(shù)據(jù)，并返回接口UserInterface實現(xiàn)類的實例化對象。

當(dāng)用戶試圖登錄系統(tǒng)時，retrieveByCredentials方法接收參數(shù)是一個驗證數(shù)組，同時他也是傳入Auth::attempt的參數(shù)。該方法會“查詢”給定的用戶驗證數(shù)據(jù)，通常，它會根據(jù)$credentials["username"]運行一個“查詢”條件語句來匹配數(shù)據(jù)。請不要用本方法進(jìn)行任何密碼的校驗或驗證。

方法validateCredentials會通過對比$user和$credentials來驗證用戶。例如，方法中會對$user->getAuthPassword();得到的字符串和$credentials["password"]通過Hash::make加密后的結(jié)果進(jìn)行對比。

上面我們探索了UserProviderInterface中的各個方法，接下來看一看UserInterface接口。記住，上面提供器中的retrieveById和retrieveByCredentials方法返回的就是本接口實現(xiàn)類的實例化對象：

interface UserInterface {

    public function getAuthIdentifier();
    public function getAuthPassword();

}

接口很簡單。getAuthIdentifier返回用戶的“主鍵索引”。在MySQL后臺存儲系統(tǒng)中，這里就指代用戶表的主鍵自增索引。getAuthPassword返回用戶密碼的哈希值。這種接口的實現(xiàn)方式使認(rèn)證系統(tǒng)和User類完全分離，并能在各種類型的實現(xiàn)下正常工作，而不用關(guān)心我們用的是ORM方式還是其他存儲層實現(xiàn)的方式。在app/models下，Laravel已經(jīng)實現(xiàn)了該接口的User類，你可以參考下這個類。

實現(xiàn)接口UserProviderInterface后，我們就做好了將我們的擴(kuò)展注冊進(jìn)Auth門面的準(zhǔn)備：

Auth::extend("riak", function($app)
{
    return new RiakUserProvider($app["riak.connection"]);
});

在method注冊之后，我們就能在app/config/auth.php中切換新的驗證驅(qū)動了。

幾乎所有Laravel框架包含的服務(wù)提供器都是作為對象綁定到IoC容器中的。在配置文件app/config/app.php中有詳細(xì)的列表。有時間的話，最好過一遍源碼。這樣，你能了解框架都加載了哪些服務(wù)，也就是容器中綁定的各式的服務(wù)。

比如，PaginationServiceProvider把paginator綁定到容器中，他對應(yīng)的是IlluminatePaginationEnvironment的實例。你可以很容易的通過擴(kuò)展重寫這些類并重新綁定到容器中。又如，我們來擴(kuò)展下基礎(chǔ)的Environment類：

namespace SnappyExtensionsPagination;

class Environment extends IlluminatePaginationEnvironment {

    //

}

擴(kuò)展完成之后，在創(chuàng)建一個新的SnappyPaginationProvider服務(wù)提供器，并在boot方法中替換掉原有的paginator：

class SnappyPaginationProvider extends PaginationServiceProvider {

    public function boot()
    {
        App::bind("paginator", function()
        {
            return new SnappyExtensionsPaginationEnvironment;
        }

        parent::boot();
    }

}

注意，本類繼承的PaginationServiceProvider，并不是默認(rèn)的ServiceProvider。當(dāng)完成擴(kuò)展之后要記住app/config/app.php中替換成自己的擴(kuò)展名稱。

這就是對容器中已經(jīng)綁定的核心類庫進(jìn)行擴(kuò)展的方法。實際上，所有核心類庫都能用這種方式進(jìn)行重寫。深入閱讀源碼，能幫你熟練知曉Laravel是怎么將各個部分組織在一起運轉(zhuǎn)的。

因為在每個請求的生命周期中，請求是很早就會被實例化的一個最基礎(chǔ)的部分，所以Request的擴(kuò)展會有稍許不同。

首先，還是像往常一樣實現(xiàn)一個子類：

namespace QuickBillExtensions;

class Request extends IlluminateHttpRequest {

    // Custom, helpful methods here...

}

然后，打開bootstrap/start.php，它是請求到達(dá)應(yīng)用時最早被包含的文件。注意這里被執(zhí)行的第一個動作就是創(chuàng)建Laravel的實例化對象$app：

$app = new IlluminateFoundationApplication;

當(dāng)對象被創(chuàng)建，同時也會創(chuàng)建IlluminateHttpRequest實例，并以request鍵綁定到IoC容器中。這里，我們應(yīng)該另辟途徑實現(xiàn)一個類來作為“默認(rèn)的”請求類型，對不對？還好，requestClass方法就能幫我們那實現(xiàn)它！所以我們需要在bootstrap/start.php文件開頭加上這樣一行：

use IlluminateFoundationApplication;

Application::requestClass("QuickBillExtensionsRequest");

當(dāng)添加玩自定義的請求類后，Laravel在任何地方都能用到我們的這個自定義的Request實例，這能使我們實現(xiàn)的定義請求類的實例可用，甚至在單元測試中也能使用。