php - Laravel 5 命令总线的最佳实践

Question

我正在尝试重构 Controller 并查看了 Laravel 的命令总线。

在阅读了一堆文章并观看了一些视频后，我觉得这可能是重构我的 Controller 的好方法。

但是，似乎我不应该从命令返回任何内容。

When using commands you follow the Command-query separation (CQS) principle: a function is either a query (i.e. it returns something) or a command (i.e. it affects state). Both are mutually exclusive. So a command is not supposed to return anything and a query is not supposed to modify anything. source

我已经创建了命令CreateCustomerCommand:

namespace App\Commands;

use QuickBooks_IPP_Service_Customer;

use App\Commands\Command;
use Illuminate\Contracts\Bus\SelfHandling;

class CreateCustomer extends Command implements SelfHandling
{
    private $qb;
    private $customer_service;
    private $customer;
    private $is_same_address;
    private $name;
    private $primary_phone;
    ...

    /**
     * Create a new command instance.
     *
     * @return void
     */
    public function __construct()
    {
        $this->qb = Quickbooks::Instance();
        $this->qb->ipp->version(QuickBooks_IPP_IDS::VERSION_3);

        $this->customer_service = new QuickBooks_IPP_Service_Customer();

        $this->is_same_address = $request->input('customer.isSameAddress');
        $this->name = ucwords(strtolower($request->input('customer.name')));
        $this->primary_phone = $request->input('customer.primaryPhone');
    }
    ...

    /**
     * Execute the command.
     *
     * @return void
     */
    public function handle()
    {
        $this->customer->setDisplayName($this->name);

        ...

        $this->customer_service->add(...);



    }
}

关于最佳实践的三个问题:

1. 调用 $this->customer_service->add() 后，返回一个客户 id。如何将此 id 发送回 Controller ？

2. 将事件日志合并到哪里最好？

事件:

$activity = new Activity();
$activity->event = 'Created Customer: ' . $this->name;
$activity->user = Auth::user()->name;
$activity->save();

将它包含在 CreateCustomerCommand 的末尾是不是最好？

1. 事件怎么样？

事件:

event(new CustomerWasCreatedOrUpdated);

我是应用程序架构的新手，正在寻找一种方法来使我的 Controller 简单易维护。如果有人能指出我正确的方向，我会很高兴。

Answer 1

首先，感谢您努力使您的 Controller “简单且可维护”。您可能并不总能实现这一目标，但实现这一目标往往会有所收获。

如何将 ID 发送回 Controller ？

命令是一般服务的特例。您的命令可以自由声明额外的公共(public)方法来查询更改状态的结果。如果命令由 CLI 应用程序使用，则该应用程序可能会执行类似 echo $this->command->getAddedCustomerId() 的操作。基于网络的 Controller 可以类似地使用它。

但是，您引用的建议——要么在没有输出的情况下更改状态，要么在有输出的情况下进行查询——是明智的。如果您正在更改状态并且您需要知道更改该状态的结果，那么您可能正在滥用命令。

作为类比，考虑 Linux 命令“useradd”，您可以像 useradd -m 'Clara Barton' cbarton 那样调用它。该命令运行并仅向您提供成功或失败指示。但请注意，您给了它主键，“cbarton”。您可以独立查询该 key ，例如 grep cbarton/etc/passwd，但重要的是 useradd 没有为您创建 ID。

总而言之，更改状态的命令最多应该告诉您成功或失败。如果您希望检查该状态更改的结果，您应该为命令提供定位状态更改所需的键。

所以您可能需要的是一般服务。命令可能使用该服务， Controller 可能使用该服务，模型可能使用该服务。但服务只是执行一项工作并为您提供必要 API 的通用类。

将事件日志合并到哪里？

假设您不使用 PHP-AOP，则应预先建立谨慎而严格的事件日志记录实践，并在整个开发生命周期中遵循。

在很大程度上，事件日志的位置取决于系统的主要架构模型。如果您严重依赖事件，那么一个好地方可能是 Event 门面的扩展或日志事件。如果您广泛依赖 DI，那么您可以在您决定需要记录的代码中传递 Logger。

在命令的特定情况下，您可以采用任何一种方式，同样取决于您的主要架构模型。如果您避开事件，那么您将通过 Laravel 的正常类型提示 DI 注入(inject)记录器。如果您利用事件，那么您可能会执行类似 Event::fire('log', new LogState('Blah Blah', compact ($foo, $bar)));

也就是说，最重要的是您依赖于可插拔和可配置的日志记录服务，您可以根据测试、QA 和生产需求更换和调整该服务。

事件呢？

嗯，事件很棒。直到他们不是。根据我的经验，事件真的会变得复杂，因为它们在 IMO 中被滥用来传递数据和影响状态。

事件就像传送器:你沿着一条路径前进，然后事件触发，突然间你被传送到整个代码库并突然出现在一个完全不同的地方，然后你做了一些事情然后被丢弃马上回到你原来的地方。当事件发生时，您必须以某种方式思考并高效地遵循代码。

如果 Laravel 事件是您第一次接触事件，我不鼓励您大量使用它们。相反，我建议您将它们限制在一个特定的包或应用程序的一部分，直到您感受到它们提供的功能以及它们所需的架构和开发严谨性。