声明:本文并非博主原创,而是来自对《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实例,这能使我们实现的定义请求类的实例可用,甚至在单元测试中也能使用。