4

我已经研究了一段时间的演员模型,并试图弄清楚如何正确地将它与 RESTful API 结合起来。我正在努力如何通过使用 ask-pattern 或 actor-per-request 来分离两层的职责。对于这两种模式,请求-回复语义都会泄漏到参与者模型中,这似乎是一种反模式。大多数由 HTTP 请求发起的消息发送给参与者都需要回复。接收参与者有多个条件,它需要向无法满足请求的 API 发出信号。

此外,关于输入验证的良好做法是什么;这是否应该作为 HTTP 的一部分来实现(例如,如果字段 X 是有效的电子邮件地址,如果字段 Y 包含整数)。对于复杂的域逻辑,当(预)条件失败时,参与者如何/应该通知发送者?

4

1 回答 1

5

虽然请求/回复是参与者间通信中的一种反模式,但在您从参与者系统外部使用它的方式上没有任何障碍。您可以Ask从那里使用Forward+Tell返回原始发件人的组合来发送回复,而不必在参与者内部使用请求/回复模型。

当涉及到输入验证时,可以在 Web 框架级别轻松完成简单的验证(字段存在、电子邮件格式等)。然而,更高级的案例(如权限管理)可能会使用参与者 - 至少如果您的业务逻辑也使用它们。

对于复杂的场景——试着用协议来思考。描述参与者和/或外部服务之间的一组契约,并使用消息来控制逻辑流。这种推理通常很难描述,但用铅笔画出来通常很容易;)

即你可能决定使用某种类型的AuthorizationGateactor,它给出一个未经授权的请求,将验证它:在身份验证失败时,它将一些RequestFailed消息发送回原始发送者(询问者),成功时它可以将该消息转换为ValidRequest并将其发送到负责处理该消息类型的参与者。然后一个actor(只处理有效请求),处理它,发送RequestSucceedRequestFailed返回给原始发送者(记住要么将该发送者存储为消息字段,或者使用actorRef.Forward而不是actorRef.Tell,这样你就不会覆盖它)。

于 2016-05-16T22:03:39.180 回答