Quelles sont les différences entre le middleware front-end et le middleware back-end de ThinkPHP6 ?

Dans le dernier exemple, nous avons appris à définir le middleware et compris la signification du middleware. Ensuite, nous avons feuilleté le manuel et en avons trouvé un autre appelé « pré-middleware » et « post-middleware ». Quelle est la différence entre les deux ?

1. La différence dans les définitions.

Il n'est pas difficile de trouver dans le manuel du site officiel que les définitions du pré-middleware et du post-middleware sont différentes. Jetons un coup d'œil ci-dessous.

Définition pré-middleware :

<?php
namespace app\middleware;
class Before
{
    public function handle($request, \Closure $next)
    {
        // 添加中间件执行代码
        return $next($request);
    }
}

Post-middleware :

<?php
namespace app\middleware;
class After
{
    public function handle($request, \Closure $next)
    {
        $response = $next($request);
        // 添加中间件执行代码
        return $response;
    }
}

Après un examen plus approfondi, j'ai découvert qu'en dernière analyse, les deux sont du code d'exécution et $next . ($request) problème d'ordre, c'est cet ordre qui est la clé du pré-middleware et du post-middleware.

2. $request est différent.

Nous pouvons imprimer les codes suivants respectivement dans le pré-middleware et le post-middleware :

halt($request);

Nous avons soigneusement comparé et constaté que les contrôleurs et les méthodes du pré-middleware le middleware est vide, le post-middleware peut obtenir le nom et la méthode du contrôleur. Donc, si nous voulons obtenir le contrôleur et la méthode actuellement consultés, nous devons utiliser un post-middleware pour le résoudre.

3. Le middleware intercepte le scénario de connexion.

Jetons d'abord un coup d'œil à la définition du middleware proposée sur le site officiel :

Le middleware est principalement utilisé pour intercepter ou filtrer les requêtes HTTP des applications et effectuer les opérations nécessaires. traiter avec.

En voyant la définition du site officiel, vous pensez peut-être qu'utiliser un middleware pour l'interception des connexions est vraiment la meilleure chose. Mais faut-il utiliser le pré- ou le post-middleware ?

<?php
namespace app\middleware;
class After
{
    public function handle($request, \Closure $next)
    {
        $response = $next($request);
        // 添加中间件执行代码
        if(empty(&#39;session&#39;)){
            echo &#39;登录不合法&#39;;
            //跳转到登录页面
        }
        return $response;
    }
}

Page d'accueil du backend :

public function index(){
    echo '后台首页';
}

Le résultat de l'exécution constatera que nous pouvons toujours exécuter la méthode d'index avant le saut de connexion et que nous pouvons afficher le contenu.

Par conséquent, le post-middleware ne peut pas être utilisé dans les scénarios de connexion. Le pré-middleware est la meilleure solution pour intercepter la connexion. À ce stade, il est également nécessaire de déterminer si l'accès actuel est une connexion. , de nombreux problèmes apparaîtront lors de la redirection, les amis doivent donc bien gérer cela.

Ce qui précède est l'introduction pertinente au pré- et post-middleware. Dans les projets réels, nous déterminons s'il convient d'utiliser le pré- ou le post-middleware en fonction de notre logique métier réelle.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!