Laravel - 5.3 changements majeurs dans le processus d'exécution du middleware !

Question

Personne en Chine n'utilise la dernière version. N'avez-vous pas remarqué ce changement logique ? N'avez-vous pas vérifié la connexion de l'utilisateur dans le constructeur (vous avez des problèmes si vous ne l'avez pas remarqué) ?
Aidez-moi à lire cette réponse officielle : https://github.com/laravel/fr...
**Mon anglais n'est pas bon ! S'il vous plaît, expliquez! Une amélioration très importante dans laravel5.3
Pourquoi faites-vous cela ?
Comment dois-je écrire une nouvelle logique ? **
La raison pour laquelle j'ai besoin de cette amélioration et comment je peux résoudre ma logique !

Je doute que cela invalide __construct
Il est plus raisonnable que le middleware except soit ajouté au middleware en tant qu'attribut !
protected $sauf =['login','register','oauth_callback'];
Tangled : cela semble déraisonnable d'ajouter ceci (ce serait déraisonnable si plusieurs groupes appellent cela), n'ajoutez pas ceci et écrivez-le pour un seul login_ _construct se sent encore mal !

Réponse actuelle : Celui du premier étage est en fait OK, mais celui-ci est beaucoup plus élégant
Description de CallAction : https://laravel.com/api/maste...

Laravel 5.3, qui est de toute façon le dernier, mis à jour à chaque fois !
Il y a maintenant ces 3, middleware, contrôleur et constructeur
Il y a 2 fonctions qui doivent être instanciées dans le constructeur. Et il doit être connecté. L’instanciation n’est pas autorisée sans connexion.
Constructeur :

Middleware :

Méthode :

Sortie :

---

Sur le parcours

---

Middleware personnalisé

Selon la sortie logique de Laravel :
2 Constructeur
1 Middleware
3 Ceci est une promotion

Mais dans ce cas, le constructeur est instancié sans se connecter, et peu importe où le middleware est placé, le constructeur sera exécuté en premier, puis le middleware
Le résultat que je veux est :
1 middleware, déterminez la connexion, pas de Jump. après la connexion
2Constructeur, instancié après la connexion
3C'est une promotion, exécutez la promotion !
Comment modifier la logique ? Je dois me connecter avant d'appeler la méthode publique. Si je ne suis pas connecté, je passerai à la connexion (hors inscription et connexion) !

Le problème probable est que Laravel doit d'abord exécuter le constructeur, puis le middleware peut être appelé.
Ensuite, quel type de logique dois-je utiliser pour répondre à mes exigences ?

$this->wx_api();
$this->agent();

Ces deux courants sont généralement écrits en __construct !

Je suis toujours confus. Selon le bon sens, si elle est définie dans le routeur, la classe de jugement a cette méthode, puis le middleware est appelé à ce moment-là, puis le constructeur est exécuté, puis la méthode ! Comment un tel processus a-t-il pu se produire !

---

Pour le problème de méthode approximatif, voir ce qui suit (vous ne pouvez pas sauter dans le constructeur, et écrire echo et exit dans laravel sera super moche. Quoi qu'il en soit, je ne peux pas le supporter. La démonstration ci-dessus est purement visuelle !)

http://laravelacademy.org/pos...
Après y avoir réfléchi attentivement, j'ai découvert que cela détruit parfaitement l'exigence de séparation des responsabilités orientée objet et améliore avec succès le degré de couplage
À cause de cette phrase, j'ai pensé Utilisez le middleware ! (Lequel est le meilleur ? Je suis un débutant et je ne sais même pas comment le dire !)

---

Laravel 5.3 est une méthode de construction du middleware -> Construction du contrôleur -> Exécution du middleware -> Exécution du middleware du contrôleur ->

Answer 1

J'utilise la dernière version 5.3 en Chine

5.3 a en effet changé la logique d'implémentation du middleware

Correspondance d'itinéraire - lire le middleware d'itinéraire - instancier le contrôleur - lire la touche centrale du contrôleur - exécuter le middleware - exécuter l'action路由匹配 - 读取路由中间件 - 实例化Controller - 读取Controller中间键 - 执行中间件 - 执行action

个人不鼓励在Controller的构造函数中初始化方法，除了使用中间件调用之外，不要做任何逻辑判断的事情。

重写 CallAction 在 CallAction中逻辑判断

因为任何一个路由的匹配都会使用CallAction

Personnellement, il n'est pas encouragé à initialiser les méthodes dans le constructeur de Controller. Ne faites aucun jugement logique sauf en utilisant des appels middleware.

Réécrivez CallAction pour porter un jugement logique dans CallAction

Parce que toute correspondance d'itinéraire utilisera CallAction pour appeler la méthode dans le contrôleur🎜 🎜🎜Dans les versions inférieures à 5.3, le middleware sera exécuté en premier, puis le contrôleur sera initialisé. C'est la plus grande différence par rapport à la version 5.3. 🎜🎜

Answer 2

Le constructeur doit être exécuté en premier, il ne semble donc y avoir aucun problème. . .

J'ai parcouru la documentation de laravel5.3. Maintenant, le middleware est exécuté après la construction. Soit vous passez à d'autres versions inférieures, soit vous n'utilisez pas le middleware, soit vous écrivez toutes les méthodes que votre constructeur d'origine appelle dans le middleware.

Par exemple : (Remarque : cette fonctionnalité nécessite la version 5.3.4 ou supérieure de Laravel)

public function __construct() {

    $this->middleware(function ($request, $next) {
        $this->wx_api();
        return $next($request);
    });
}

public function wx_api () {
    
}