本文译自 Matt Stauffer 的 系列文章 . 如果你有阅读我之前的 Laravel 5.0 系列文章，你可能已经注意到路由过滤器(route filters)的变化：它们先是移到了单独的目录和类结构，然后就莫名其妙地消失了。你可能还留意到在原本应该是路由过滤器的地方，变成了对 Middleware 的引用。 实际上给 Laravel 应用添加自定义的 Middleware 在以前的版本中就有了。 Chris Fidao 的 HTTP Middleware in Laravel 4.1 对 middleware 做了全面的介绍，包括 middleware 在 Laravel 4.1 版本中的工作机制。
提示：过滤器在 Laravel 核心代码中依然存在，所以你依然可以使用。但是在需要对路由进行修饰时，更推荐采用的是 middleware. Middleware 是什么？ Middleware 有点不好理解。你可以先看看下面这张从 StackPHP 借来的图。假设你的应用——路由，控制器，业务逻辑——是图中的绿色部分，从图中可以清晰地看到，用户请求先经由多个中间层才能到达你的应用，然后再经由更多的中间层进行处理。每个特定的中间层都可以在应用逻辑之前、之后进行处理，或者同时在应用逻辑之前和之后进行处理。
这就是 middleware 实现修饰模式的工作方式：它捕获请求，做一些处理，然后把处理后的请求对象返回给下一个堆栈层。Laravel 默认使用 middleware 来处理加密/解密和 cookies 队列、读取和写入 sessions, 但除此之外你还可以用 middleware 来向请求/响应环中加入你需要的任何一种操作层。比如速率限制、自定义请求解析等。怎么编写 middleware?通过执行 artisan 命令：$ php artisan make:middleware MyMiddleware这条命令会生成一个简单的 middleware 文件，代码如下：namespace App/Http/Muse Cuse Illuminate/Contracts/Routing/Mclass MyMiddleware implements Middleware { /** * 处理输入请求 * * @param/Illuminate/Http/Request$request * @param/Closure$next * @return mixed */ public function handle($request, Closure $next) {
// }} 如你所见，所有 middleware 的基础是 handle 方法，它接受两个参数：
$request : Illuminate Request 对象
$next : Closure(匿名函数), 该函数把 request 对象传递给后续的 middleware.
还记得之前那个荒谬的 “阻止奇数端口请求的 ValidatesWhenResolved 对象” 的例子吗？很好，现在再把它拿过来，改成 middleware 风格的： namespace App/Http/Muse Cuse Illuminate/Contracts/Routing/Mclass MyMiddleware implements Middleware {/** * Handle an incoming request. * * @param/Illuminate/Http/Request$request * @param/Closure$next * @return mixed */public function handle($request, Closure $next){// Test for an even vs. odd remote portif (($request-&server-&get('REMOTE_PORT') / 2) % 2 & 0){throw new /Exception(&WE DON'T LIKE ODD REMOTE PORTS&);}return $next($request);}}如何使用 Middleware? 在 Laravel 5 中有两种主要的方法可以绑定 middleware. 两种方法都从 App/Http/Kernel 开始。
你可能注意到了，新的 Kernel 类有两个属性： $middleware 和 $routeMiddleware . 这两个属性都是 middleware 为元素的数组。在 $middleware 中的 middleware 会在每次请求时运行，而 $routeMiddleware 中的 middleware 必须被启用才会运行。
在本文写作时， $middleware 中默认包含的有五个 middlewares: protected $middleware = [ 'Illuminate/Foundation/Http/Middleware/CheckForMaintenanceMode', 'Illuminate/Cookie/Middleware/EncryptCookies', 'Illuminate/Cookie/Middleware/AddQueuedCookiesToResponse', 'Illuminate/Session/Middleware/StartSession', 'Illuminate/View/Middleware/ShareErrorsFromSession', 'Illuminate/Foundation/Http/Middleware/VerifyCsrfToken',];此外还有三个可选的 middlewares:protected $routeMiddleware = ['auth' = 'App/Http/Middleware/Authenticate','auth.basic' =& 'Illuminate/Auth/Middleware/AuthenticateWithBasicAuth','guest' =& 'App/Http/Middleware/RedirectIfAuthenticated',];从上面的代码中可以看到， 在新版本中默认可用的可选路由 middleware 与旧版本中默认可用的可选过滤器(filter)是一样的，除了一个例外——CSRF 表单保护在新版本中默认是对所有路由默认启用的——这非常重要。在每次请求时执行 middleware 下面，我们从让自己的 middleware 在每次请求时都执行开始。很简单，只要把它加到 $middleware 数组中： protected $middleware = [ 'App/Http/Middleware/MyMiddleware', // 这是自定义的 'Illuminate/Foundation/Http/Middleware/CheckForMaintenanceMode', 'Illuminate/Cookie/Middleware/EncryptCookies', 'Illuminate/Cookie/Middleware/AddQueuedCookiesToResponse', 'Illuminate/Session/Middleware/StartSession', 'Illuminate/View/Middleware/ShareErrorsFromSession', 'Illuminate/Foundation/Http/Middleware/VerifyCsrfToken',];现在每次请求时它都会被执行了。在特定的路由上执行 middlewareOK, 接下来把我们的自定义 middleware 移到可选堆栈，要给它指定一个 key:protected $routeMiddleware = ['auth' = 'App/Http/Middleware/Authenticate','auth.basic' =& 'Illuminate/Auth/Middleware/AuthenticateWithBasicAuth','guest' =& 'App/Http/Middleware/RedirectIfAuthenticated','absurd' =& 'App/Http/Middleware/MyMiddleware', // 这是自定义的]; 现在我们可以在 routes.php 文件中或者在基础控制器(BaseController)中用 $this-&middleware() 方法来调用自定义的 middleware 了。 在控制器中调用：...use Illuminate/Routing/Cclass AwesomeController extends Controller { public function __construct() {
$this-&middleware('csrf');
$this-&middleware('auth', ['only' =& 'update']) }}在 routes.php 文件中调用：// Routes.php// Single route$router-&get(&/awesome/sauce&, &&, ['middleware' =& 'auth']);// Route group$router-&group(['middleware' =& 'auth'], function() {// lots of routes that require auth middleware}); 如何通过 middleware 实现 before 和 after 过滤器？
我花了一些时间来研究这个问题，但 Taylor(译注：Laravel 框架作者) 指出了 &before& middleware 和 &after& middleware 的区别在于 middleware 的行为是发生在它调用 $next() 之前还是之后： ...class BeforeMiddleware implements Middleware { public function handle($request, Closure $next) {
// Do Stuff
return $next($request); }}...class AfterMiddleware implements Middleware { public function handle($request, Closure $next) {
$response = $next($request);
// Do stuff
return $ }} 如你所见， &before& middleware 先执行操作，然后把请求向堆栈传递。而 &after& middleware 是先调用 $next() 方法让请求被堆栈处理，之后再对它执行操作。 写在最后如果你还不熟悉 middleware, 你的大脑可能会被它的概念纠缠一会儿。从我们考虑控制器及路由请求的常规思维方式的角度来说，过滤器(filter)会更容易理解一些。但 middleware ——这种在堆栈中传递单一请求，让它一点一点被处理的概念——其实更整洁、更简单、更灵活。不仅如此，middleware 不只是在 Laravel 应用中处理请求的额外的一种强大而高效的手段，它在其它方面也能有很好的表现。Laravel 5.0 中的 middleware 语法与 StackPHP 的语法不完全兼容。但如果你采用基于 middleware 的架构来组织你的请求/响应堆栈，这是在依赖关系分离方向上的一个进步。而且要修改一个 Laravel middleware 使之可以在单独的 StackPHP 风格的语法下工作，也花不了多少工夫。 有任何意见，欢迎留下评论或者通过 Twitter 与 @stauffermatt 进行交流。
无相关信息
最新教程周点击榜
微信扫一扫Laravel5（1）
在Laravel中，如果我们需要自定义路由，例如把app/Http/routes.php文件被移动到routes目录下，并且分割成两个文件：web.php和api.php。
可以修改App\Providers\RouteServiceProvider文件，参考以下代码获取思路：
public function map(Router $router)
$this-&mapWebRoutes($router);
$this-&mapApiRoutes($router);
protected function mapWebRoutes(Router $router)
$router-&group([
'namespace' =& $this-&namespace,
'middleware' =& 'web',
], function ($router) {
require base_path('routes/web.php');
protected function mapApiRoutes(Router $router)
$router-&group([
'middleware' =& ['api'],
'namespace' =& $this-&namespace,
'prefix' =& 'api',
], function ($router) {
require base_path('routes/api.php');
本文参考了破洛洛网站中的《修改Laravel5.3中的路由文件与路径》一文。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：8159次
排名：千里之外
(2)(1)(2)(1)(1)(2)(5)(4)}