Jonas Bonr 的依赖注入策略似乎有限制——但也许我不明白它

Question

我已经读过这篇文章好几次了：

http: //jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html

我想我明白了。然而，有些事情我不太明白。

查看他的 UserService 示例，我发现他设置了 UserRepositoryComponent 来封装 UserRepository。但我不明白的是为什么 UserRepositoryComponent 扮演两个角色：它封装 UserRepository 并提供对 UserRepository 对象的引用。

我试图想象如果我想创建一个依赖于两个 UserRepository 实例的服务，我将如何使用此模式。也许新服务的工作是将用户从“源”UserRepository 复制到“目标”UserRepository。所以我想象的是这样的：

trait CopyUserServiceComponent {
  val source: UserRepositoryComponent
  val destination: UserRepositoryComponent
  class CopyUserServiceComponent { 
    ... 
  }
}

但这与原来的模式不同。在本例中，我在组件本身中定义依赖项，而不是从其他组件继承它们。但在我看来，这是正确的方法：组件应该声明它们的依赖项，而不是它们包含的服务的实例。

我在这里缺少什么？

Answer 1

在这种情况下，我在组件本身中定义依赖项，而不是从其他组件继承它们。

蛋糕模式不使用继承来声明依赖关系。您在 UserServiceComponent 中看到任何“扩展”吗？

但在我看来，这是正确的方法：组件应该声明它们的依赖项，而不是其包含的服务的实例。

但这正是蛋糕模式的作用：声明依赖关系！也许如果示例包含 def userRepositoryFactory = new UserRepository 而非 val userRepository = new UserRepository ，情况会更清楚吗？

那么，让我们回到你的例子：

trait CopyUserServiceComponent {
  val source: UserRepositoryComponent
  val destination: UserRepositoryComponent
  class CopyUserServiceComponent { 
    ... 
  }
}

让我们看看我们不能用它做的事情：

trait CopyUserServiceComponent {
  // The module will need to see my internals!
  private val source: UserRepositoryComponent
  private val destination: UserRepositoryComponent
  class CopyUserServiceComponent { 
    ... 
  }
}

trait CopyBigUserServiceComponent extends CopyServiceComponent {
  // Any change in implementation will have to be reflected in the module!
  val tmp: UserRepositoryComponent
  ...
}

另一方面......

trait UserRepositoryComponent {
  val userRepositoryFactory: () => UserRepository

  class UserRepository {
    ...
  }
} 

trait CopyUserServiceComponent {
  self: UserRepositoryComponent =>
  // No problem here
  private val source: UserRepository = userRepositoryFactory()
  private val destination: UserRepository = userRepositoryFactory()
  class CopyUserServiceComponent { 
    ... 
  }
}

trait CopyBigUserServiceComponent extends CopyServiceComponent {
  self: UserRepositoryComponent =>
  // No problem here either
  val tmp: : UserRepository = userRepositoryFactory()
  ...
}

编辑

补充答案，让我们考虑两个不同的需求：

• 我需要许多 UserRepository 实例。

在这种情况下，您在错误的级别应用了该模式。在 Jonas 的示例中，UserRepository 处于工厂提供单例的级别。

因此，在这种情况下，您不会执行 UserRepository 和 UserRepositoryComponent，而是执行 UserRepositoryFactory 和 UserRepositoryFactoryComponent。

• 我正好需要两个单例UserRepository。

在这种情况下，只需执行以下操作：

trait UserRepositoryComponent {
  val sourceUserService: UserService
  val destinationUserService: UserService

  class UserService ...
}

Answer 2

我认为，乔纳斯在他的文章中提到了一种广泛接受的构建可扩展应用程序的方法称为复合软件构建，用几句话可以解释如下：整个应用程序（在元级别上编排）是由独立组件构建的程序集，而这些组件又是其他组件和服务的组合。就复合软件而言，'cake'（示例中的ComponentRegistry对象）是组件（'UserServiceComponent'和'UserRepositoryComponent'）等的集合。而在示例中组件包含服务实现，这在现实世界中几乎不可能发生。

在您的示例中，您不需要定义内部类 - 您可以将工作流程放入普通方法中：

trait CopyUserServiceComponent {
  val source: UserRepositoryComponent
  val destination: UserRepositoryComponent

  def copy = {...}
}

它完全符合原始模式 - 蛋糕的基本功能不仅是通过自类型注释指定依赖项，而且还能够从具体实现中抽象出来，直到您需要从组件构建程序集的那一刻。