Commandes et tâches de Laravel

je me demandais quelle était la différence entre les différentes classes command-like de Laravel 5.1. Pour autant que je puisse dire Laravel 5.1 dispose de la suivante:

  • commandes de la Console ( artisan make:console )
  • commandes ( artisan make:command )
    • Gestionnaires ( artisan make::command --handler )
  • Emplois ( artisan make:job )

je suis venu directement de 4.2 à 5.1 donc je ne sais pas ce qui s'est passé entre 4.2 et 5.1, mais on m'a dit que les commandes du milieu ( juste ) ne sont pas vraiment supposées être utilisées plus - elles sont là depuis que les jobs en file d'attente sont devenus des 'commandes' en 5.0, mais Laravel a depuis décidé de ne pas le faire, et elles sont juste là pour la compatibilité. Cependant, je ne suis pas à 100% sur ce point, donc une clarification serait appréciée.

mon cas d'utilisation spécifique est que je veulent un endroit pour mettre un 'exécutable' tâche. Par exemple, quelque chose qui supprimera les fichiers de plus de 5 jours d'un répertoire donné (mais qui pourrait faire n'importe quoi).

au début cela sonne comme une commande de console - je veux pouvoir l'exécuter à partir de artisan , pour un démarrage. Mais je peux également le vouloir sur un programme (grand, artisan schedule:run exécute les commandes de la console). Mais je peux aussi vouloir l'exécuter asynchrone à partir du code. Les commandes de la Console peuvent être exécutées synchrone avec Artisan::call() , mais pour asynchrone, c'est (je pense) là que les files d'attente entrent en jeu, et ça doit soudainement être un travail.

Ok donc on a un boulot. Nous pouvons maintenant l'ajouter à une file d'attente à partir du code, mais comment l'exécutons-nous en tant que commande artisanale (synchrone)? Puis-je créer une commande de console fine et y ajouter le trait DispatchesJobs (ou le code qui s'y trouve), puis y envoyer le travail? Fait le travail toujours à aller sur une file d'attente, ou peut-on faire un travail exécuter de façon synchrone (et, idéalement, la sortie vers la sortie de la commande de la console?) La même question se pose pour l'exécuter sur un schedule - suis-je censé créer cette commande de console et l'ajouter au scheduler, ou Puis-je faire exécuter le travail directement par le scheduler?

et finalement, nous avons des 'commandes' qui ne sont pas des commandes de console ni des jobs. Comme je l'ai déjà dit, les gens me disent que ce ne sont que des accroches à un changement de code Laravel 5.0 qui a été (en quelque sorte) inversé. Mais l' artisan make commande existe toujours pour eux, donc ils ne peuvent pas être que morts. En outre, qu'est-ce qui se passe avec une commande d'auto-manipulation (la valeur par défaut, est fournie avec une méthode handle ) et une commande qui "nécessite" une classe handler (exécuter artisan make:command --handler )? Comment avez-vous fait faire de ces les exécuter? Manuellement avec (new AppCommandSomeCommand)->handle(); ou (new ApphandlersSomeCommandHandler)->handle(new AppCommandSomeCommand) , ou y a-t-il un système caché que je ne connais pas (peut-être qu'ils peuvent être envoyés en utilisant le job/file dispatcher)? Vous pouvez aussi créer'file d'attente' commandes artisan make::command --queued , alors en quoi diffèrent-elles aussi?

je suppose que ma question se résume à ceci:

  • Quelle est la différence réelle (sémantique et fonctionnelle) entre eux tous?
  • Quelle est la bonne façon de les "exécuter"?
  • ce qui est le mieux pour mes fins d'un bit de code généralement autonome qui doit être exécuté, de quelque manière que je me sens approprié?

j'ai trouvé des informations dans la documentation sur la façon d'utiliser les files d'attente et de créer des commandes de console, mais rien sur le moment exact où les utiliser ou vraiment rien sur les classes de commande et les gestionnaires.

Liées mais pas exactement le même (d'ailleurs, c'est sans réponse): Laravel 5.1 commandes et de l'emploi

22
demandé sur Community 2015-08-19 15:11:43

3 réponses

je vois ces "objets" comme ceci: (j'ai ajouté quelques exemples de code d'un de mes projets secondaires)

Console

choses que je veux exécuter à partir de la ligne de commande (comme vous l'avez mentionné avec votre exemple avec"Supprimer des fichiers plus anciens que x"). Mais la chose est, vous pouvez extraire la logique métier de commande .

exemple : une commande de console avec une commande de fetch les images de Imgur. La classe FetchImages contient la logique commerciale actuelle de la recherche d'images.

commande

classe qui contient la logique réelle. Vous devriez également pouvoir appeler cette commande depuis votre application avec app()->make(Command::class)->handle() .

exemple : commande mentionnée dans L'exemple 1. Contient la logique qui fait les appels API réels à Imgur et traite les données retournées.

Jobs

j'ai fait cette application avec Laravel 5.0 donc jobs n'étaient pas une chose. Mais à mon avis, les tâches sont comme des commandes, mais elles sont en file d'attente et peuvent être envoyées. (Comme vous avez pu le voir dans ces exemples, ces commandes implémentent les Interfaces SelfHandling et ShouldBeQueued ).

je me vois comme un développeur Laravel expérimenté mais ces changements dans Commands et Jobs sont assez difficiles à comprendre.

EDIT: De Laravel Docs:

le répertoire app/Commandes a été renommé app/Jobs. Cependant, vous n'êtes pas obligé de déplacer toutes vos commandes vers le nouvel emplacement, et vous pouvez continuer à utiliser les commandes make:command et handler:command Artisan pour générer vos classes.

de même, le répertoire app/Handlers a été renommé app/Listeners et ne contient désormais que des écouteurs d'événements. Cependant, vous n'êtes pas tenu de déplacer ou de renommer vos gestionnaires de commandes et d'événements existants, et vous pouvez continuer à utiliser la commande handler:event pour générer des gestionnaires d'événements.

en fournissant la compatibilité ascendante pour la structure de dossier Laravel 5.0, vous pouvez mettre à jour vos applications à Laravel 5.1 et mettre à jour lentement vos événements et commandes à leurs nouveaux emplacements quand il est commode pour vous ou votre équipe.

17
répondu stefanzweifel 2016-12-27 17:09:11

Console Command

Laravel possède depuis un certain temps des "commandes" de console. Ils sont essentiellement inchangés et fonctionnent comme ils l'ont toujours fait. En termes simples, ils sont l'équivalent des voies de la ligne de commande - le point d'entrée dans l'application. Ils ne sont en aucune façon liés à l'...

Le Bus De Commande

Laravel 5.0 a introduit une mise en œuvre des commandes de Bus de configuration Command Bus . (Je crois ceux-ci ont été renommés en Jobs en raison de la confusion qui en résulte entre eux et les commandes CLI).

un bus de commande en deux parties - un objet qui représente une commande à exécuter, avec toutes les données dont il a besoin (le travail), et une classe pour exécuter la commande (le gestionnaire).

Le Gestionnaire

Dans laravel, vous pouvez déclarer un travail d'auto-manipulation - qui est, il a une poignée méthode elle-même.

si vous pour enregistrer un gestionnaire de commandes, vous pouvez appeler le fournisseur de services suivant: 

app('Illuminate\Bus\Dispatcher')->maps(['Job' => 'Handler']);

où Job est le nom de la classe pour le travail, et Handler est le nom de la classe pour le handler.

le répertoire handlers de laravel 5.0 était un moyen de déclarer implicitement ces relations (c'est-à-dire: EmailCommand dans le dossier commandes aurait un EmailCommandHandler dans le dossier handlers).

l'Envoi d'une Commande

vous pouvez utiliser ce qui suit pour envoyer une commande. 

app('Illuminate\Bus\Dispatcher')->dispatch(new EmailPersonCommand('email@you.com', $otherdata));

Files d'attente

Les Jobs

, par défaut, s'exécuteront dès qu'ils seront appelés (ou expédiés). Les Définir comme ShouldQueue les passera toujours dans une file d'attente lorsqu'ils seront expédiés.

si vous voulez les exécuter synchrones parfois, et asynchrones d'autres fois, vous pouvez appeler $dispatcher->dispatchToQueue($job) quand vous voulez qu'ils soient mis en file d'attente. C'est tout ce que ça se passe à l'interne quand on passe d'un emploi ShouldQueue à ->dispatch() .

edit: Pour de files d'attente (ou pas)

je viens de voir le répartiteur. La méthode dispatch vérifie si la commande est une ShouldQueue et la transmet à dispatchToQueue ou dispatchNow . Vous pouvez appeler l'une de ces méthodes directement au lieu de dispatch avec votre commande si vous souhaitez remplacer le comportement par défaut.

Donc dans votre cas, en fonction de ce que le "défaut" du comportement de votre travail est (ie. il va normalement être mis en file d'attente?) soit: - avoir ShouldQueue , et utiliser dispatchNow dans la commande CLI. - ne pas avoir ShouldQueue , et utiliser dispatchToQueue où vous l'appelez dans votre code.

D'après les sons, je ferais le premier.

26
répondu stef 2015-08-24 12:46:08

juste un ajout aux réponses réelles.

les emplois dans Laravel >= 5.1 sont des commandes Bus dans Laravel 5.0 .

il s'agit uniquement d'un changement de nom en raison de la confusion entre Console\Commands (commandes exécutées à partir de la console) et le Command Bus (contenant Commands ) pour les tâches D'Application.

vous ne devez pas confondre:

  • Command Bus : utilisé pour "encapsuler les tâches de votre application" (tiré de laravel 5.0 doc) qui est maintenant renommé a Jobs
  • Console\Commands : utilisé pour " Artisan [...] l'interface en ligne de commande incluse avec Laravel" (de laravel 5.1 docs) qui est inchangée dans Laravel depuis 4.x
1
répondu Ifnot 2016-02-23 09:03:03