Question

在Java世界中，它被认为是使用3层架构（表示层，服务层和DAO层）设计应用程序的最佳实践。

但我目前的应用程序使用Scala和Akka。在我的一个演员中，在收到一些消息后，我需要从DB中检索国家列表。如果我使用过Java，我很可能会创建CountryService接口及其实现，以及CountryDao和相应的实现。

但Akka的做法是什么？我应该由演员包裹CountryService吗？我认为这是个坏主意，因为在这种情况下，我的演员收到一些消息后需要发送另一条消息来检索所有国家，并在它回复原始发件人之后。

Answer 1

这完全基于我与Akka的经验，其他人可能不同意。

如果你的国家演员没有州那么就不要让它成为演员。只需使用Scala的Future API并将其传回给本应调用它的Actor即可。这样，数据库调用可以在与Actors完全不同的执行上下文中运行（您不应该在Actors内部阻塞调用）。如果您正在考虑缓存，那么我的意见是缓存仍然不是真正的状态，使用Guava Cache是线程安全的并且可以解决问题。

所以这看起来像这样：

class MyActor(countryService: CountryService) extends Actor {
  // ...
  val result: Future[Countries] = countryService.getCountries
  result.pipeTo(self)
  // ...
  def recieve = {
    case Countries(c) => // use c
  }
  // ...
}

有些情况下，您希望将其包装到单独的CountryActor中，但这些是特殊的：即您严重依赖Actor路径并希望访问特定路径上的服务actor，想要专门处理错误，有一些重试逻辑等。

Answer 2

参与者的数量与图层/服务的数量无关。每个服务可以有数千个演员，或者根本没有。取决于演员是否在这种情况下有用。

使用actor对很多事情很有用：隐藏状态，负载平衡和在孩子之间划分工作，使用“让它崩溃”模型容错：将危险工作委托给孩子并选择监督策略。

创建和使用actor非常便宜，消息发送也是如此。但是你当然不需要它们。问问自己：演员带来了哪些优势？

阿卡。我应该将所有服务/ DAO实施为演员吗？

2 个答案: