Laravel 命令和作业
Laravel commands and jobs
我想知道 Laravel 5.1 中不同的 command-like class 之间有什么区别。据我所知 Laravel 5.1 有以下可用的：
- 控制台命令（
artisan make:console）
- 命令（
artisan make:command）
- 处理程序（
artisan make::command --handler）
- 职位（
artisan make:job）
我是从 4.2 直接到 5.1 所以我不知道 4.2 和 5.1 之间发生了什么，但有人告诉我中间那个（只是 命令）基本上不应该再使用了 - 它们是从 queue-able jobs 在 5.0 中变成 'commands' 时开始的，但是 Laravel 因为决定反对这个，它们只是为了兼容性.但是，我在这一点上不是 100%，所以澄清将不胜感激。
我的具体use-case是想要一个地方放一个self-contained'runnable'任务。例如，将从给定目录中删除超过 5 天的文件的东西（但它可以做任何事情）。
起初这听起来像是一个控制台命令 - 我希望能够从 artisan 开始 运行 它。但我可能还希望按计划进行（很好，artisan schedule:run 运行s 控制台命令）。但我可能还想从代码中异步执行它。控制台命令可以是 运行 同步 和 Artisan::call()，但对于异步，这是（我认为）队列进来的地方，它突然必须成为一项工作.
好的，我们找到工作了。我们现在可以通过代码将它添加到队列中，但是我们如何将它作为 artisan 命令执行（同步）？我可以只创建一个瘦控制台命令并向其添加 DispatchesJobs 特征（或其中的代码），然后分派作业吗？作业是否总是必须排队，或者我们可以让作业同步执行（并且，理想情况下，输出到控制台命令的输出？）同样的问题也适用于 运行 按计划执行它 - 我是吗应该创建这个控制台命令并将其添加到调度程序，或者我可以让调度程序 运行 直接成为作业吗？
最后，我们有 'commands' 既不是控制台命令也不是作业。正如我之前所说，人们告诉我这些只是 hangers-on 来自 Laravel 5.0 代码更改（有点）还原。但是 artisan make 命令对他们来说仍然存在，所以他们不可能 that 死了。此外，自处理命令（默认情况下，带有 handle 方法）和 'requires' 处理程序 class （运行 artisan make:command --handler )?您实际上如何执行这些操作？手动使用 (new App\Command\SomeCommand)->handle(); 或 (new App\handlers\SomeCommandHandler)->handle(new App\Command\SomeCommand)，还是有一些我不知道的隐藏系统（也许它们可以使用 job/queue 调度程序调度）？您还可以创建 'queued' 命令 artisan make::command --queued，那么它们有何不同？
我想我的问题可以归结为以下几点：
- 它们之间真正的（语义 和 功能）区别是什么？
- 'run'它们的正确方法是什么？
- 对于需要 运行 的 generally-standalone 代码，以我认为合适的任何方式，哪个最适合我的目的？
我在文档中找到了有关如何使用队列和创建控制台命令的信息，但没有关于确切何时使用它们的信息，也没有关于命令 classes 和处理程序的任何内容。
相关但不完全相同（同样，未回答）：Laravel 5.1 commands and jobs
我看到那些“对象”是这样的：（我从我的一个副项目中添加了一些代码示例）
控制台
我想从命令行执行的事情（正如您在示例中提到的“删除早于 x 的文件”）。但问题是，您可以将它的业务逻辑提取到 command.
Example：控制台命令会触发从 Imgur 获取图像的命令。 Class FetchImages 包含获取图片的实际业务逻辑。
命令
Class 其中包含实际逻辑。您还应该能够使用 app()->make(Command::class)->handle().
从您的应用程序调用此命令
Example：示例 1 中提到的命令。包含对 Imgur 进行实际 API 调用并处理返回数据的逻辑。
职位
我用 Laravel 5.0 开发了这个应用程序，所以 jobs 在当时还不算什么。但在我看来，Jobs 就像命令，但它们是排队的，可以被调度。 （您可能已经在这些示例中看到，这些命令实现了您提到的接口 SelfHandling 和 ShouldBeQueued）。
我认为自己是一名经验丰富的 Laravel 开发人员，但 Commands 和 Jobs 中的那些变化很难理解。
编辑：
来自 Laravel 文档：
The app/Commands directory has been renamed to app/Jobs. However, you are not required to move all of your commands to the new location, and you may continue using the make:command and handler:command Artisan commands to generate your classes.
Likewise, the app/Handlers directory has been renamed to app/Listeners and now only contains event listeners. However, you are not required to move or rename your existing command and event handlers, and you may continue to use the handler:event command to generate event handlers.
By providing backwards compatibility for the Laravel 5.0 folder structure, you may upgrade your applications to Laravel 5.1 and slowly upgrade your events and commands to their new locations when it is convenient for you or your team.
控制台命令
Laravel 已经使用控制台 "commands" 一段时间了。它们基本上没有变化，并且一如既往地工作。简单来说，它们相当于命令行的路由 - 应用程序的入口点。他们与...没有任何关系
命令总线
Laravel 5.0 引入了 Command Bus 模式的实现 - 命令总线命令。 （我相信这些被重命名为 Jobs 是因为它们与 CLI 命令之间产生了混淆）。
命令总线分为两部分 - 一个表示要执行的命令的对象，包含它需要的任何和所有数据（作业），以及一个 class 来执行命令（处理程序）。
处理者
在 laravel 中，您可以声明一个作业是自处理的——也就是说，它本身有一个 handle 方法。
如果要注册命令处理程序，可以在服务提供者中调用以下命令：
app('Illuminate\Bus\Dispatcher')->maps(['Job' => 'Handler']);
其中 Job 是作业的 class 名称，Handler 是处理程序的 class 名称。
laravel 5.0 中的 handlers 目录是一种隐式声明这些关系的方式（即命令文件夹中的 EmailCommand 将在 handlers 文件夹中有一个 EmailCommandHandler）。
调度命令
您可以使用以下命令发送命令。
app('Illuminate\Bus\Dispatcher')->dispatch(new EmailPersonCommand('email@you.com', $otherdata));
队列
默认情况下，作业将在调用（或分派）后立即 运行。将它们设置为 ShouldQueue 将在调度时始终将它们传递到队列。
如果您希望有时 运行 它们同步，而其他时候异步，您可以在您希望它们排队时调用 $dispatcher->dispatchToQueue($job)。当您将 ShouldQueue 作业传递给 ->dispatch().
时，这就是内部发生的所有事情
编辑：排队（或不排队）
我刚刚仔细查看了调度程序。 dispatch 方法检查命令是否为 ShouldQueue，并将其转发给 dispatchToQueue 或 dispatchNow。如果您希望覆盖默认行为，您可以直接调用这些方法中的任何一个而不是 dispatch 使用您的命令。
所以在你的情况下，取决于你的工作的 "default" 行为是什么（即它通常会排队吗？）：
- 使用 ShouldQueue，并在 CLI 命令中使用 dispatchNow。
- 不要 ShouldQueue，在代码中调用它的地方使用 dispatchToQueue。
听起来，我会选择前者。
只是对实际答案的补充。
Laravel >= 5.1 中的作业是 Laravel 5.0.
中的命令总线
这只是一个命名更改，因为应用程序的 Console\Commands（来自控制台的命令 运行）和 Command Bus（包含 Commands）之间存在混淆任务。
你不应该混淆 :
Command Bus ：用于 "encapsulating tasks your application"（来自 laravel 5.0 文档），现在重命名为 JobsConsole\Commands ：用于 "Artisan [...] the command-line interface included with Laravel"（来自 laravel 5.1 文档）自 4.x
我想知道 Laravel 5.1 中不同的 command-like class 之间有什么区别。据我所知 Laravel 5.1 有以下可用的：
- 控制台命令（
artisan make:console） - 命令（
artisan make:command）- 处理程序（
artisan make::command --handler）
- 处理程序（
- 职位（
artisan make:job）
我是从 4.2 直接到 5.1 所以我不知道 4.2 和 5.1 之间发生了什么，但有人告诉我中间那个（只是 命令）基本上不应该再使用了 - 它们是从 queue-able jobs 在 5.0 中变成 'commands' 时开始的，但是 Laravel 因为决定反对这个，它们只是为了兼容性.但是，我在这一点上不是 100%，所以澄清将不胜感激。
我的具体use-case是想要一个地方放一个self-contained'runnable'任务。例如，将从给定目录中删除超过 5 天的文件的东西（但它可以做任何事情）。
起初这听起来像是一个控制台命令 - 我希望能够从 artisan 开始 运行 它。但我可能还希望按计划进行（很好，artisan schedule:run 运行s 控制台命令）。但我可能还想从代码中异步执行它。控制台命令可以是 运行 同步 和 Artisan::call()，但对于异步，这是（我认为）队列进来的地方，它突然必须成为一项工作.
好的，我们找到工作了。我们现在可以通过代码将它添加到队列中，但是我们如何将它作为 artisan 命令执行（同步）？我可以只创建一个瘦控制台命令并向其添加 DispatchesJobs 特征（或其中的代码），然后分派作业吗？作业是否总是必须排队，或者我们可以让作业同步执行（并且，理想情况下，输出到控制台命令的输出？）同样的问题也适用于 运行 按计划执行它 - 我是吗应该创建这个控制台命令并将其添加到调度程序，或者我可以让调度程序 运行 直接成为作业吗？
最后，我们有 'commands' 既不是控制台命令也不是作业。正如我之前所说，人们告诉我这些只是 hangers-on 来自 Laravel 5.0 代码更改（有点）还原。但是 artisan make 命令对他们来说仍然存在，所以他们不可能 that 死了。此外，自处理命令（默认情况下，带有 handle 方法）和 'requires' 处理程序 class （运行 artisan make:command --handler )?您实际上如何执行这些操作？手动使用 (new App\Command\SomeCommand)->handle(); 或 (new App\handlers\SomeCommandHandler)->handle(new App\Command\SomeCommand)，还是有一些我不知道的隐藏系统（也许它们可以使用 job/queue 调度程序调度）？您还可以创建 'queued' 命令 artisan make::command --queued，那么它们有何不同？
我想我的问题可以归结为以下几点：
- 它们之间真正的（语义 和 功能）区别是什么？
- 'run'它们的正确方法是什么？
- 对于需要 运行 的 generally-standalone 代码，以我认为合适的任何方式，哪个最适合我的目的？
我在文档中找到了有关如何使用队列和创建控制台命令的信息，但没有关于确切何时使用它们的信息，也没有关于命令 classes 和处理程序的任何内容。
相关但不完全相同（同样，未回答）：Laravel 5.1 commands and jobs
我看到那些“对象”是这样的：（我从我的一个副项目中添加了一些代码示例）
控制台
我想从命令行执行的事情（正如您在示例中提到的“删除早于 x 的文件”）。但问题是，您可以将它的业务逻辑提取到 command.
Example：控制台命令会触发从 Imgur 获取图像的命令。 Class FetchImages 包含获取图片的实际业务逻辑。
命令
Class 其中包含实际逻辑。您还应该能够使用 app()->make(Command::class)->handle().
Example：示例 1 中提到的命令。包含对 Imgur 进行实际 API 调用并处理返回数据的逻辑。
职位
我用 Laravel 5.0 开发了这个应用程序，所以 jobs 在当时还不算什么。但在我看来，Jobs 就像命令，但它们是排队的，可以被调度。 （您可能已经在这些示例中看到，这些命令实现了您提到的接口 SelfHandling 和 ShouldBeQueued）。
我认为自己是一名经验丰富的 Laravel 开发人员，但 Commands 和 Jobs 中的那些变化很难理解。
编辑： 来自 Laravel 文档：
The app/Commands directory has been renamed to app/Jobs. However, you are not required to move all of your commands to the new location, and you may continue using the make:command and handler:command Artisan commands to generate your classes.
Likewise, the app/Handlers directory has been renamed to app/Listeners and now only contains event listeners. However, you are not required to move or rename your existing command and event handlers, and you may continue to use the handler:event command to generate event handlers.
By providing backwards compatibility for the Laravel 5.0 folder structure, you may upgrade your applications to Laravel 5.1 and slowly upgrade your events and commands to their new locations when it is convenient for you or your team.
控制台命令
Laravel 已经使用控制台 "commands" 一段时间了。它们基本上没有变化，并且一如既往地工作。简单来说，它们相当于命令行的路由 - 应用程序的入口点。他们与...没有任何关系
命令总线
Laravel 5.0 引入了 Command Bus 模式的实现 - 命令总线命令。 （我相信这些被重命名为 Jobs 是因为它们与 CLI 命令之间产生了混淆）。
命令总线分为两部分 - 一个表示要执行的命令的对象，包含它需要的任何和所有数据（作业），以及一个 class 来执行命令（处理程序）。
处理者
在 laravel 中，您可以声明一个作业是自处理的——也就是说，它本身有一个 handle 方法。
如果要注册命令处理程序，可以在服务提供者中调用以下命令：
app('Illuminate\Bus\Dispatcher')->maps(['Job' => 'Handler']);
其中 Job 是作业的 class 名称，Handler 是处理程序的 class 名称。
laravel 5.0 中的 handlers 目录是一种隐式声明这些关系的方式（即命令文件夹中的 EmailCommand 将在 handlers 文件夹中有一个 EmailCommandHandler）。
调度命令
您可以使用以下命令发送命令。
app('Illuminate\Bus\Dispatcher')->dispatch(new EmailPersonCommand('email@you.com', $otherdata));
队列
默认情况下，作业将在调用（或分派）后立即 运行。将它们设置为 ShouldQueue 将在调度时始终将它们传递到队列。
如果您希望有时 运行 它们同步，而其他时候异步，您可以在您希望它们排队时调用 $dispatcher->dispatchToQueue($job)。当您将 ShouldQueue 作业传递给 ->dispatch().
编辑：排队（或不排队）
我刚刚仔细查看了调度程序。 dispatch 方法检查命令是否为 ShouldQueue，并将其转发给 dispatchToQueue 或 dispatchNow。如果您希望覆盖默认行为，您可以直接调用这些方法中的任何一个而不是 dispatch 使用您的命令。
所以在你的情况下，取决于你的工作的 "default" 行为是什么（即它通常会排队吗？）：
- 使用 ShouldQueue，并在 CLI 命令中使用 dispatchNow。
- 不要 ShouldQueue，在代码中调用它的地方使用 dispatchToQueue。
听起来，我会选择前者。
只是对实际答案的补充。
Laravel >= 5.1 中的作业是 Laravel 5.0.
中的命令总线这只是一个命名更改，因为应用程序的 Console\Commands（来自控制台的命令 运行）和 Command Bus（包含 Commands）之间存在混淆任务。
你不应该混淆 :
Command Bus：用于 "encapsulating tasks your application"（来自 laravel 5.0 文档），现在重命名为JobsConsole\Commands：用于 "Artisan [...] the command-line interface included with Laravel"（来自 laravel 5.1 文档）自 4.x 以来在 Laravel 中没有变化