【发布时间】：2021-09-06 06:05:27
【问题描述】：
在我的工作中，我们目前正在努力使用 Web 应用程序中的 uuid 生成方法。 我们做 DDD，我们的持久存储是我们拥有的远程 API。
这是我的代码的简化示例：
class HireFooHandler() {
private $repository;
private $mailer;
public function __construct(FooRepository $repository, HiringMailer $mailer, ... ) {
$this->repository = $repository; //behind the repository, there are api calls
$this->mailer = $mailer;
...
}
public function handle(HireFooCommand $command) {
try {
$foo = new Foo($command->uuid, $command->baz, ...);
$this->repository->hire($foo);
$this->mailer->sendHiredMail($foo);
...
} catch(...) {
...
}
}
}
我的一些同事对生成 uuid 并将其发送到 api 的应用程序不满意。 他们更喜欢让服务器端处理 uuid 生成，如果在此示例中保存了“foo”，则在响应中将生成的 uuid 发送回应用程序。 主要论点是，api 也将是公开的，他们不希望客户端必须生成 uuid。
另一方面，从我的应用程序和编码的角度来看，由于我的实体 Foo 不应该处于无效状态，要创建它，我必须提供 uuid 并从客户端生成它，我觉得还可以。
所以我在这里苦苦挣扎，不知道最好的方法是什么，以及在哪里生成我的 uuid？客户端 ？服务器端？
我建议他们通过在可以验证的 post 端点中添加一个 uuid 可选字段来使 api 更加灵活。所以 Api 可以从客户端接收一个 uuid，如果没有生成它自己的。 但我不确定这是一个好习惯。
如果有人有一些意见，我会很高兴阅读它:)
【问题讨论】：
-
有趣的问题，但它是基于意见的，可能不会在这个板上获得太大的吸引力。对我自己来说，100% 的客户端主要是因为我很少单独创建实体。通常它更像是一棵带有子实体的树，我宁愿提前设置所有 id 而不是尝试处理返回值。在我看来，拥有一个可选的 uuid 似乎是两全其美。选择一种或另一种方法。
-
在服务器上生成 UUID 有什么困扰？最后没关系，一个UUID就是一个UUID，不管是在服务端生成还是在客户端生成。在客户端上生成它可能会提供更多的灵活性，因为由于客户端提前知道参考 ID，它可能会在之前的操作中将其用作相关 ID，但这也意味着每个客户端都有一个 UUID 生成器，并且服务器必须验证输入。只要在持久化实体之前生成 ID，我认为两者都可以。
-
我首先关心的是保持有效的代码。根据定义，如果我需要引用一个实体，它就有一个身份（uuid）。所以理论上我不应该在没有 uuid 的情况下实例化我的实体，否则它将处于无效状态。此外，如果 api 负责在保存时创建 uuid 并且 API 由于任何原因失败并且不向我发送 uuid 响应，我必须再次调用它。但是 api 可以在第一次工作并保存实体。因此，如果我再次调用它，我将使用不同的 uuid 保存 2 个实体“Foo”。我们失去了幂等性，我的 rest api 不可靠。
-
我发现从客户端创建UUID有几个好处，例如，客户端想要创建一个实体，所以我认为客户端应该负责提供所有实体信息；幂等更容易处理；单元测试更容易
标签： php domain-driven-design uuid api-design