plantillas - Laravel comandos y trabajos

laravel foreach index

Question

Me preguntaba cuál es la diferencia entre las diferentes clases de comando en Laravel 5.1. Por lo que puedo decir, Laravel 5.1 tiene lo siguiente disponible:

• Comandos de consola ( artisan make:console )
• Comandos ( artisan make:command )
  • Manejadores ( artisan make::command --handler )
• Trabajos ( artisan make:job )

Vengo directamente de 4.2 a 5.1, así que no sé qué sucedió entre 4.2 y 5.1, pero me han dicho que el del medio ( solo comandos) básicamente no se debe usar más. cuando los trabajos en cola se convirtieron en ''comandos'' en 5.0, pero Laravel desde entonces decidió no hacerlo, y solo están dentro de la compatibilidad. Sin embargo, no estoy al 100% en este punto, por lo que se agradecería una aclaración.

Mi caso de uso específico es que quiero un lugar para poner una tarea ''ejecutable'' autocontenida. Por ejemplo, algo que eliminará los archivos de más de 5 días de un directorio determinado (pero podría hacer cualquier cosa).

Al principio, esto suena como un comando de consola: quiero poder ejecutarlo desde el punto de vista de un artisan , para empezar. Pero es posible que también lo quiera en una programación (excelente artisan schedule:run comandos de la consola). Pero también podría querer ejecutarlo de forma asíncrona desde el código. Los comandos de la consola se pueden ejecutar de forma síncrona con Artisan::call() , pero para asíncronos, esto es (creo) donde entran las colas, y de repente tiene que ser un trabajo.

Está bien, así que tenemos un trabajo. Ahora podemos agregarlo a una cola desde el código, pero ¿cómo lo ejecutamos como un comando artesanal (sincrónicamente)? ¿Puedo crear un comando de consola delgada y agregarle el rasgo DispatchesJobs (o el código en él), y luego enviar el trabajo? ¿El trabajo siempre tiene que ir en una cola, o podemos hacer que un trabajo se ejecute de forma sincrónica (y, idealmente, la salida a la salida del comando de la consola?) La misma pregunta se aplica a una programación: ¿se supone que debo crear esta consola? ordene y agregue eso al programador, o ¿puedo hacer que el programador ejecute el trabajo directamente?

Y, finalmente, tenemos ''comandos'' que no son comandos de consola ni son tareas. Como dije antes, la gente me dice que estos son solo suspensiones de un cambio de código Laravel 5.0 que fue (un poco) revertido. Pero el comando de artisan make todavía existe para ellos, por lo que no pueden estar tan muertos. Además, ¿cuál es el trato con un comando de auto-manejo (el predeterminado, viene con un método de handle ) y uno que ''requiere'' una clase de controlador (ejecutar artisan make:command --handler )? ¿Cómo se hacen realmente estas ejecuciones? Manualmente con (new App/Command/SomeCommand)->handle(); o (new App/handlers/SomeCommandHandler)->handle(new App/Command/SomeCommand) , o hay algún sistema oculto que no conozco (tal vez se puedan enviar con el despachador de trabajo / cola)? También puede crear comandos "en cola" de forma artisan make::command --queued , entonces, ¿en qué se diferencian también?

Supongo que mi pregunta se reduce a lo siguiente:

• ¿Cuál es la diferencia real (semántica y funcional) entre todas ellas?
• ¿Cuál es la forma correcta de ''ejecutar'' ellos?
• ¿Cuál es mejor para mis propósitos de un bit de código generalmente independiente que se debe ejecutar, de la manera que me parezca más apropiada?

Encontré información en la documentación sobre cómo usar colas y crear comandos de consola, pero no tengo información exactamente sobre cuándo usarlos o realmente nada en las clases de comandos y los controladores.

Relacionados pero no exactamente iguales (también, no tiene respuesta): comandos y trabajos de Laravel 5.1

Answer 1

Comandos de consola

Laravel ha tenido "comandos" de consola durante algún tiempo. Básicamente no han cambiado y funcionan como siempre lo han hecho. En términos simples, son el equivalente de las rutas para la línea de comando: el punto de entrada a la aplicación. De ninguna manera están relacionados con ...

El bus de comando

Laravel 5.0 introdujo una implementación del patrón del Bus de Comando - Comandos del Bus de Comando. (Creo que se cambió su nombre a Jobs debido a la confusión resultante entre ellos y los comandos de la CLI).

Un bus de comandos como dos partes: un objeto que representa un comando que se debe ejecutar, con todos los datos que necesita (el trabajo), y una clase para ejecutar el comando (el controlador).

El manejador

En laravel, puede declarar que un trabajo es auto manejable, es decir, tiene un método de manejo en sí mismo.

Si desea registrar un controlador de comandos, puede llamar a lo siguiente en un proveedor de servicios:

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

donde Trabajo es el nombre de clase para el trabajo y Controlador es el nombre de clase para el controlador.

El directorio de manejadores en laravel 5.0 era una forma de declarar implícitamente esas relaciones (es decir, EmailCommand en la carpeta de comandos tendría un EmailCommandHandler en la carpeta de manejadores).

Despachando un comando

Puede usar lo siguiente para enviar un comando.

app(''Illuminate/Bus/Dispatcher'')->dispatch(new EmailPersonCommand(''[email protected]'', $otherdata));

Colas

Los trabajos, de forma predeterminada, se ejecutarán tan pronto como se llamen (o se envíen). Establecerlos como ShouldQueue siempre los pasará a una cola cuando se envíen.

Si desea ejecutarlos de forma síncrona a veces, y asíncronamente otras veces, puede llamar a $dispatcher->dispatchToQueue($job) cuando desee que estén en cola. Esto es todo lo que sucede internamente cuando pasa un trabajo ShouldQueue a ->dispatch() .

editar: Para hacer cola (o no)

Acabo de echar un vistazo más largo al despachador. El método de dispatch comprueba si el comando es ShouldQueue y lo reenvía a dispatchToQueue o dispatchNow . Puede llamar a cualquiera de estos métodos directamente en lugar de dispatch con su comando si desea anular el comportamiento predeterminado.

Entonces, en su caso, dependiendo de cuál sea el comportamiento "predeterminado" de su trabajo (es decir, ¿normalmente se pondrá en cola?): - debe tener ShouldQueue , y use dispatchNow en el comando de la CLI. - no lo tenga ShouldQueue , y use dispatchToQueue donde lo llame en su código.

Por lo que parece, yo haría lo primero.

Answer 2

Sólo una adición a las respuestas reales.

Los trabajos en Laravel> = 5.1 son comandos Bus en Laravel 5.0 .

Es solo un cambio de nombre debido a la confusión entre Console/Commands (los comandos se ejecutan desde la consola) y el Command Bus (que contiene los Commands ) para las tareas de la aplicación.

No debes confundir:

• Command Bus : se usa para "encapsular tareas en su aplicación" (del documento laravel 5.0) que ahora se renombra a Jobs
• Console/Commands : se usa para "Artisan [...] la interfaz de línea de comandos incluida con Laravel" (de la documentación de laravel 5.1) que no ha cambiado en Laravel desde 4.x

Answer 3

Veo esos "objetos" así: (agregué algunos ejemplos de código de uno de mis proyectos paralelos)

Consola

Cosas que quiero ejecutar desde la línea de comandos (como mencionó en su ejemplo con "Eliminar archivos anteriores a x"). Pero la cuestión es que podría extraer la lógica de negocios de un comando .

Example : Un comando de la consola con dispara un comando para obtener imágenes de Imgur. La clase FetchImages contiene la lógica empresarial real de la FetchImages de imágenes.

Mando

Clase que contiene la lógica actual. También debería poder llamar a este comando desde su aplicación con app()->make(Command::class)->handle() .

Example : Comando mencionado en el Ejemplo 1. Contiene la lógica que realiza las llamadas de API reales a Imgur y procesa los datos devueltos.

Trabajos

Hice esta aplicación con Laravel 5.0 por lo que los jobs no eran una cosa en ese entonces. Pero como lo veo, los trabajos son como comandos pero están en cola y se pueden enviar. (Como puede haber visto en esos ejemplos, esos comandos implementan las Interfaces SelfHandling y ShouldBeQueued ).

Me considero un desarrollador de Laravel experimentado, pero esos cambios en Commands y Jobs son bastante difíciles de entender.

EDITAR: De los documentos de Laravel:

El directorio app / Commands ha sido renombrado a app / Jobs. Sin embargo, no es necesario que mueva todos sus comandos a la nueva ubicación, y puede continuar usando los comandos make: command y handler: command Artisan para generar sus clases.

Del mismo modo, el directorio app / Handlers ha cambiado su nombre a app / Listeners y ahora solo contiene detectores de eventos. Sin embargo, no es necesario que mueva o cambie el nombre de sus comandos existentes y los controladores de eventos, y puede continuar usando el comando controlador: evento para generar los controladores de eventos.

Al proporcionar compatibilidad con versiones anteriores para la estructura de carpetas de Laravel 5.0, puede actualizar sus aplicaciones a Laravel 5.1 y actualizar lentamente sus eventos y comandos a sus nuevas ubicaciones cuando sea conveniente para usted o su equipo.