声明：本文并非博主原创，而是来自对《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基类，他为每个具体的管理器提供了很多常见使用的方法。

缓存 Cache

我们通过在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 会话

扩展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中切换新的验证驱动了。

基于IoC容器的扩展

几乎所有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实例，这能使我们实现的定义请求类的实例可用，甚至在单元测试中也能使用。