Comandos y trabajos de Laravel

Question

Comandos y trabajos de Laravel

Me preguntaba cuál es la diferencia entre las diferentes clases tipo 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)
Empleos (artisan make:job)

He venido directamente de 4.2 a 5.1, así que no se lo que pasó entre 4.2 y 5.1, pero me han dicho que el del medio (solo comandos) son básicamente, ya no se supone que se usen - ya están desde que los trabajos capaces de hacer cola se convirtieron en 'comandos' en 5.0, pero Laravel decidió no hacerlo, y solo están en busca de compatibilidad. Sin embargo, no estoy 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' autónoma. Por ejemplo, algo que eliminará archivos de más de 5 días de un directorio dado (pero podría hacer nada).

Al principio esto suena como un comando de consola - quiero ser capaz de ejecutarlo desde artisan, para empezar. Pero también puede que lo desee en un horario (genial, artisan schedule:run ejecuta comandos de consola). Pero también puedo querer ejecutarlo asincrónicamente desde el código. Los comandos de consola se pueden ejecutar sincrónicamente con Artisan::call(), pero para asíncronos, aquí es (creo) donde entran las colas, y de repente tiene que ser un trabajo.

Bien, así que tenemos un trabajo. Ahora podemos añadirlo a una cola desde el código, pero ¿cómo lo ejecutamos como un comando artisan (sincrónicamente)? ¿Puedo crear un comando de consola delgada y agregarle el rasgo DispatchesJobs (o el código que contiene), 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 (e, idealmente, se genere en la salida del comando de la consola?) La misma pregunta va para ejecutarlo en un horario-se supone que debo crear este comando de consola y agregarlo al programador, o puedo hacer que el programador ejecute el trabajo directamente?

Y finalmente, tenemos 'comandos' que no son comandos de consola ni son trabajos. 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 artisan maketodavía existe para ellos, por lo que no pueden estar que muertos. Además, ¿cuál es el trato con un comando de auto manejo (el predeterminado, viene con un método handle) y uno que 'requiere' una clase de controlador (run artisan make:command --handler)? ¿Cómo haces que se ejecuten? Manualmente con (new App\Command\SomeCommand)->handle(); o (new App\handlers\SomeCommandHandler)->handle(new App\Command\SomeCommand), o hay algún sistema oculto que desconozco (tal vez se puedan enviar usando el despachador de trabajo/cola)? También puede crear comandos' en cola ' artisan make::command --queued, entonces, ¿en qué difieren estos también?

Supongo que mi pregunta se reduce a lo siguiente: {[15]]}

¿Cuál es la diferencia real (semántica y funcional) entre todos ellos?
¿Cuál es la forma correcta de 'ejecutarlos'?
Que es mejor para mis propósitos de un en general-bit independiente de código que necesita ser ejecutado, de cualquier manera me siento apropiado?

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

Relacionado pero no exactamente el mismo (también, está sin respuesta): Comandos y trabajos Laravel 5.1

22

laravel jobs laravel-5 laravel-5.1

Author: Community, 2015-08-19

Source

3 answers

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 rutas para la línea de comandos - el punto de entrada en la aplicación. No están relacionados de ninguna manera...

El Bus de Comandos

Laravel 5.0 introdujo una implementación de los comandos Bus Command Bus pattern - Command. (Creo que estos fueron renombrados a Puestos de trabajo debido a la confusión resultante entre ellos y Comandos CLI).

Un bus de comandos como dos partes - un objeto que representa un comando a ser ejecutado, con todos los datos que necesita (el trabajo), y una clase para ejecutar el comando (el manejador).

El Controlador

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

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 Job es el nombre de clase para el trabajo, y Handler es el nombre de clase para el handler.

El directorio handlers en laravel 5.0 era una forma de declarar implícitamente esas relaciones (ie. EmailCommand en la carpeta commands tendría un EmailCommandHandler en la carpeta handlers).

Enviando un Comando

Puede usar lo siguiente para enviar un comando.

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

Colas

Los trabajos, por defecto, se ejecutarán tan pronto como sean llamados (o enviados). Configurarlos como ShouldQueue siempre será pásalos a una cola cuando sean enviados.

Si desea ejecutarlos sincrónicamente a veces, y asincrónicamente otras veces, puede llamar a $dispatcher->dispatchToQueue($job) cuando desee que estén en cola. Esto es todo lo que sucede internamente cuando se pasa un trabajo ShouldQueue a ->dispatch().

Editar: Hacer cola (o no)

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

Así que en su caso, dependiendo de cuál sea el comportamiento "predeterminado" de su trabajo (es decir. ¿estará normalmente en cola?) bien: - tenerlo ShouldQueue, y usar dispatchNow en el Comando CLI. - no lo tenga ShouldQueue, y use dispatchToQueue donde lo llame en su código.

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

26

Author: stef,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-08-24 12:46:08

Solo una adición a las respuestas reales.

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

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

No debes confundir:

Command Bus: se utiliza para" encapsular tareas de su aplicación " (de laravel 5.0 doc) que ahora se rebautiza como Jobs
Console\Commands: se utiliza para " Artesano [...] la interfaz de línea de comandos incluida con Laravel " (de laravel 5.1 docs) que no ha cambiado en Laravel desde 4.x

1

Author: Ifnot,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2016-02-23 09:03:03

score 17 · Accepted Answer

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 mencionaste en tu ejemplo con "Eliminar archivos anteriores a x"). Pero la cosa es, se podría extraer la lógica de negocio de la misma a un comando .

Ejemplo : Un comando de consola con dispara un comando para obtener imágenes de Imgur. La Clase FetchImages contiene la lógica de negocio real de la obtención images.

Comando

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

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

Trabajos

Hice esta aplicación con Laravel 5.0 así que jobs no eran una cosa en ese entonces. Pero como yo lo veo, los trabajos son como comandos pero están en cola y pueden ser despachados. (Como usted puede han visto en esos ejemplos, esos comandos implementan sus Interfaces mencionadas SelfHandling y ShouldBeQueued).

Me veo a mí mismo como un desarrollador experimentado de Laravel, 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 el comando make: y el comando handler: Comandos artesanales para generar tus clases.

Del mismo modo, el directorio app/Handlers ha sido renombrado a app/Listeners y ahora solo contiene listeners de eventos. Sin embargo, no es necesario que mueva o cambie el nombre de los controladores de comandos y eventos existentes, y puede continuar utilizando el comando handler:event para generar controladores de eventos.

Al proporcionar compatibilidad hacia atrás para la estructura de carpetas 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.