Laravel深入学习7 - 框架的扩展

摘要：组件扩展通常有两种方法向容器中绑定自己的接口实现痛过使用工厂模式实现的类注册自己的扩展。类库管理类以工厂模式实现，负责诸如缓存等驱动的实例化。闭包须要传入继承自和容器的实例化对象。当完成扩展之后要记住中替换成自己的扩展名称。

声明：本文并非博主原创，而是来自对《Laravel 4 From Apprentice to Artisan》阅读的翻译和理解，当然也不是原汁原味的翻译，能保证90%的原汁性，另外因为是理解翻译，肯定会有错误的地方，欢迎指正。

欢迎转载，转载请注明出处，谢谢！

Laravel为我们提供了很多自定义系统组件的扩展点，你甚至可以完全的替换掉他们。比如，哈希结构是由HasherInterface接口约定的，你可以根据你的应用来实现自己的需求。你也可以扩展自己的Request对象，并添加自己的“辅助”方法。甚至我们完全添加自己的认证、缓存、SESSION驱动。

Laravel组件扩展通常有两种方法：向IoC容器中绑定自己的接口实现；痛过使用“工厂模式”实现的Manager类注册自己的扩展。本章将探索多种扩展框架的方法，以及必要的测试代码。

扩展方式
牢记Laravel组件扩展的两种方式：IoC容器绑定和使用Manager类注册。类库管理类以工厂模式实现，负责诸如缓存、session等驱动的实例化。

Laravel有诸多Manager类库来管理创建那些基于驱动的组件。它包括缓存、session、认证、队列组件。管理类的职责是根据应用的配置来创建特殊的驱动实例。例如，CacheManager可以创建APC、Memcached、Native、以及其他缓存驱动系统的实现。

所有这些管理器都有个extend方法，可以轻易的将新的驱动功能注入到其中。对于上面所有的管理器，我们通过实例来演示如何注入我们自定义的那些服务驱动。

学习我们自己的管理器
请花一些事件来熟悉下Laravel提供的Manager类库，如CacheManager、SessionManager。通读这些代码可以让你加深理解。所有的管理器类都继承自IlluminateSupportManager基类，他为每个具体的管理器提供了很多常见使用的方法。

我们通过在CacheManager类中的extend方法绑定自定义的驱动解析器来扩展Laravel的缓存机制。比如，注册一个“mongo”驱动到缓存驱动中，代码如下：

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

传入method方法的第一个参数是驱动名称。通常和app/config/app.php配置文件中的driver选项匹配。第二个参数是返回IlluminateCacheRepository实例的闭包。闭包须要传入继承自IlluminateFoundationApplication和IoC容器的实例化对象$app。

对于我们自定义的缓存驱动，要实现IlluminateCacheStoreInterface接口的约定。因此，我们的MongoDB缓存实现代码为这样：

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连接来实现上述类中的各个方法即可。当完成上述实现，就可完成我们自定义的驱动注册：

use IlluminateCacheRepository;

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

如上可见，我们可使用IlluminateCacheRepository来直接创建我们自定义的缓存驱动，而无需创建自己的（Repository）仓库类。

如果不知道该把代码放在哪里，可以考虑放到Packagist！或者在应用主目录下创建一个Extensions命名空间的目录存放。例如你的应用起名叫个Snappy，可以把这个扩展放到app/Snappy/Extensions/MongoStore.php。Laravel创建的应用没有死板的各种结构的要求，根据你的喜好自己来组织就好。

何处引入扩展
如果你还在考虑该在何处引入扩展，不妨继续使用服务提供器。我们已经讨论过这是组织我们代码的一个利器，要善用利器。

扩展Session机制其实像扩展缓存机制一样简单。同样，使用extend方法来注册我们自己的驱动：

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

注意，我们自定义的驱动须要实现SessionHandlerInterface接口。此接口是被包含在PHP5.4+核心中的。如果你在使用PHP5.3，Laravel也是向前兼容的，Laravel已经为您定义好此接口。接口中包含了一些我们须要实现的方法。一个基于MongoDB实现的驱动代码如下：

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方法一般是在基于文件系统的实现中被用到。自从Laravel基于以PHP自身的本地存储实现了native会话驱动方式，你基本上不需要在本方法中添加任何东西了。你可以把他留空。PHP这种接口设计很显然是一种不好的设计方式（我们后续讨论）。

close方法同open方法，通常不用理会。大多数驱动都不需要他。

read方法返回根据$sessionId变量关联session数据的字符串。这里不需要进行序列化或者其他类型的转义，Laravel已经帮你进行了处理。

write方法根据$sessionId关联session数据将$data数据写入持久化存储系统中，如MongoDB、Dynamo等。

gc方法将根据$lifetime指定UNIX时间戳销毁之前所有的session数据。对于可以自动删除过期数据的系统比如Memcached或者Redis，该方法留空即可。

当实现SessionHandlerInterface之后，我们就可以向Session管理器中注册他了：

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

当会话驱动注册之后，在配置文件app/config/session.php中指定mongo配置就能使用我们自定义的session驱动了。

分享你的成果
记住，如果你实现了自己的session驱动，可以在Packagist上分享给大家！

类似缓存和会话扩展，我们继续从method方法开始：

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

接口UserProviderInterface的实现指责是从各种持久化存储系统如MySQL、Riak等中获取数据，并返回接口UserInterface实现的对象。这两个接口可以让Laravel专注于验证本身，而无需关心用户数据的存储实现，以及用户对象是那种类来表示的问题。

让我们先看一下UserProviderInterface接口：

interface UserProviderInterface {

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

}

retrieveById方法通常接收的参数是一个唯一标识符，例如MySQL数据库中的主键自增索引ID。该方法将获取$identifier对应的数据，并返回接口UserInterface实现类的实例化对象。

当用户试图登录系统时，retrieveByCredentials方法接收参数是一个验证数组，同时他也是传入Auth::attempt的参数。该方法会“查询”给定的用户验证数据，通常，它会根据$credentials["username"]运行一个“查询”条件语句来匹配数据。请不要用本方法进行任何密码的校验或验证。

方法validateCredentials会通过对比$user和$credentials来验证用户。例如，方法中会对$user->getAuthPassword();得到的字符串和$credentials["password"]通过Hash::make加密后的结果进行对比。

上面我们探索了UserProviderInterface中的各个方法，接下来看一看UserInterface接口。记住，上面提供器中的retrieveById和retrieveByCredentials方法返回的就是本接口实现类的实例化对象：

interface UserInterface {

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

}

接口很简单。getAuthIdentifier返回用户的“主键索引”。在MySQL后台存储系统中，这里就指代用户表的主键自增索引。getAuthPassword返回用户密码的哈希值。这种接口的实现方式使认证系统和User类完全分离，并能在各种类型的实现下正常工作，而不用关心我们用的是ORM方式还是其他存储层实现的方式。在app/models下，Laravel已经实现了该接口的User类，你可以参考下这个类。

实现接口UserProviderInterface后，我们就做好了将我们的扩展注册进Auth门面的准备：

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

在method注册之后，我们就能在app/config/auth.php中切换新的验证驱动了。

几乎所有Laravel框架包含的服务提供器都是作为对象绑定到IoC容器中的。在配置文件app/config/app.php中有详细的列表。有时间的话，最好过一遍源码。这样，你能了解框架都加载了哪些服务，也就是容器中绑定的各式的服务。

比如，PaginationServiceProvider把paginator绑定到容器中，他对应的是IlluminatePaginationEnvironment的实例。你可以很容易的通过扩展重写这些类并重新绑定到容器中。又如，我们来扩展下基础的Environment类：

namespace SnappyExtensionsPagination;

class Environment extends IlluminatePaginationEnvironment {

    //

}

扩展完成之后，在创建一个新的SnappyPaginationProvider服务提供器，并在boot方法中替换掉原有的paginator：

class SnappyPaginationProvider extends PaginationServiceProvider {

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

        parent::boot();
    }

}

注意，本类继承的PaginationServiceProvider，并不是默认的ServiceProvider。当完成扩展之后要记住app/config/app.php中替换成自己的扩展名称。

这就是对容器中已经绑定的核心类库进行扩展的方法。实际上，所有核心类库都能用这种方式进行重写。深入阅读源码，能帮你熟练知晓Laravel是怎么将各个部分组织在一起运转的。

因为在每个请求的生命周期中，请求是很早就会被实例化的一个最基础的部分，所以Request的扩展会有稍许不同。

首先，还是像往常一样实现一个子类：

namespace QuickBillExtensions;

class Request extends IlluminateHttpRequest {

    // Custom, helpful methods here...

}

然后，打开bootstrap/start.php，它是请求到达应用时最早被包含的文件。注意这里被执行的第一个动作就是创建Laravel的实例化对象$app：

$app = new IlluminateFoundationApplication;

当对象被创建，同时也会创建IlluminateHttpRequest实例，并以request键绑定到IoC容器中。这里，我们应该另辟途径实现一个类来作为“默认的”请求类型，对不对？还好，requestClass方法就能帮我们那实现它！所以我们需要在bootstrap/start.php文件开头加上这样一行：

use IlluminateFoundationApplication;

Application::requestClass("QuickBillExtensionsRequest");

当添加玩自定义的请求类后，Laravel在任何地方都能用到我们的这个自定义的Request实例，这能使我们实现的定义请求类的实例可用，甚至在单元测试中也能使用。