Nie*_*sma 4 actor-model actor akka.net
我\xe2\x80\x99 已经研究 actor 模型有一段时间了，并试图找出如何将其与 RESTful API 正确结合。我\xe2\x80\x99m正在努力如何通过使用ask-pattern或actor-per-request来分离两层的职责。对于这两种模式，请求-回复语义都会泄漏到参与者模型中，这看起来像是一种反模式。大多数由 HTTP 请求发起、发送给参与者的消息都需要回复。接收参与者有多个条件，需要向 API 发出它无法满足请求的信号。
\n\n此外，在输入验证方面什么被认为是良好实践；是否应该将其作为 HTTP 的一部分来实现（例如，如果字段 X 是有效的电子邮件地址，如果字段 Y 包含整数）。对于复杂的域逻辑，当（前置）条件失败时，参与者如何/应该通知发送者？
\n虽然请求/回复是参与者间通信中的反模式，但没有什么可以阻止你从参与者系统外部使用它。您可以Ask从那里使用Forward+的组合Tell返回原始发件人发送回复，而不必在参与者内部使用请求/回复模型。
当涉及到输入验证时，简单的验证（字段存在、电子邮件格式等）可以在 Web 框架级别轻松完成。然而，更高级的案例（例如权限管理）可能会使用参与者 - 至少如果您的业务逻辑也使用它们的话。
对于复杂的场景 - 尝试用协议来思考。描述参与者和/或外部服务之间的一组契约，并使用消息来控制逻辑流。通常很难描述这种推理，但用铅笔画出来通常很容易;)
也就是说，您可能决定使用某种AuthorizationGate参与者，它给出未经授权的请求，将验证它：在身份验证失败时，它会将一些RequestFailed消息发送回原始发送者（询问者），在成功时，它可以将该消息转换为ValidRequest并发送给负责处理该消息类型的参与者。然后，一个参与者（仅处理有效的请求）处理它，发送RequestSucceed或RequestFailed返回到原始发送者（记住将该发送者存储为消息字段，或使用 actorRef.Forward 而不是 actorRef.Tell，这样就不会覆盖它）。