Laravel 5.0 - Annotations d'événements (supprimées)

Laravel 5.0 – Annotations d’événements (supprimées)

Remarque : Les annotations d’événements ont finalement été supprimées du noyau et séparées dans un package géré par la communauté Laravel. Le package doit fonctionner de la même manière que la documentation ici, sauf qu’il nécessite la liaison d’un fournisseur de services personnalisé. Les commentaires peuvent aller aux problèmes Github pour le projet ou à @artisangoose dans le mou Larachat.

Dans la version 5.0, Laravel déplace de plus en plus les liaisons et définitions procédurales de niveau supérieur, amorcées, vers une structure plus orientée objet et axée sur la séparation des préoccupations. Les filtres sont désormais des objets, les contrôleurs ont désormais un espace de noms, la logique d’application chargée par PSR-4 est désormais séparée de la configuration du framework, et plus encore.

Nous avons vu dans le dernier article que les annotations sont l’une des façons dont Laravel 5.0 apporte ce changement. Là où les routes étaient liées les unes après les autres dans routes.php, elles peuvent maintenant être liées avec des annotations sur les définitions de classe et de méthode du contrôleur.

La mise en scène

Une autre partie de Laravel qui a traditionnellement été liée à une liste d’appels les uns après les autres est les écouteurs d’événements, et c’est la prochaine cible de la syntaxe d’annotation.

Considérez le code suivant :

Event::listen('user.signup', function($user)
{
    $intercom = App::make('intercom');
    $intercom->addUser($user);
});

Quelque part dans votre code – dans un fournisseur de services, peut-être, ou peut-être juste dans un fichier global quelque part – vous avez lié un écouteur (la fermeture ci-dessus) à l’événement “user.signup”.

Bien sûr, vous avez probablement remarqué que la fermeture ne fait qu’appeler une seule méthode, nous pourrions donc la refactoriser en ceci :

Event::listen('user.signup', 'Intercom@addUser');

Présentation des annotations d’événement

Maintenant, supprimons complètement le besoin de liaison et remplaçons-le par une annotation.

<?php namespace App;

class Intercom
{
    /**
     * @Hears("user.signup")
     */
    public function addUser(User $user)
    {
        return $this->api_wrapper->sendSomeAddThing(
            $user->email,
            $user->name
        );
    }
}

Comme vous pouvez le voir, le @Hears l’annotation peut prendre un nom d’événement de chaîne, mais elle peut également prendre un tableau de noms d’événements (dans les annotations, les tableaux sont entourés de {} au lieu de []).

Vous devez également ajouter le nom de vos classes à la $scan propriété sur le EventServiceProvider. Alors, ouvrez App/Providers/EventServiceProvider.phptrouvez le $scan tableau et mettez-le à jour :

<?php
...
    protected $scan = [
        'App\Intercom'
    ];

Maintenant, cours artisan event:scan et vous obtiendrez un fichier nommé storage/framework/events.scanned.phpavec le contenu suivant :

<?php

$events->listen(array (
  0 => 'user.signup',
), 'App\Intercom@addUser');

Instantanément lié.

Conclusion

Il y a des avantages et des inconvénients à travailler avec votre système d’événements de cette façon.

Le principal négatif que je vois est que vous pourriez considérer cette annotation comme étant spécifique au framework ; si tel est le cas, vous placez maintenant le code spécifique au framework directement dans votre domaine. Si vous imaginez que cette classe Intercom est quelque chose que vous faites passer entre plusieurs sites, sa liaison peut être spécifique à ce site, auquel cas vous feriez mieux d’utiliser le style de liaison classique. Cependant, ce n’est pas toujours le cas.

Notez que ce négatif est différent de la même situation dans les annotations de route, qui ne sont appliquées qu’aux contrôleurs – qui ne sont pas des objets de domaine.

Les points positifs que je peux voir à première vue, vous définissez d’abord l’acte d’écoute de la méthode sur la méthode elle-même, plutôt qu’ailleurs ; et deuxièmement, que vous définissez l’écouteur de manière à ce qu’il puisse être accessible par programmation (ce qui signifie que vous pouvez, à tout moment, remplacer artisan event:scan avec un programme de votre propre conception qui produit quelque chose autre qu’un Laravel events.scanned déposer). Il y a probablement des gens plus intelligents que moi qui vont peser là-dessus.