如何使用依赖解析器？

Question

我有一个小问题。对于无损架构，我使用依赖注入。 如何在我的其他类之间共享此依赖关系解析器？这个解析器应该是一个带有一些实例的全局静态列表的静态类，或者我应该这样做非静态的，并将此解析器通过属性或构造函数传递给其他类？我认为，你应该做这个非静态的，因为如果你用一个单独的静态解析器来做这件事，那么你对这个解析器有依赖性。

Answer 1

你可以有两种类型的解析器。

• 一个地方你的依赖被使用的构造像解决：

  MyClass myClass; 
  public MyConstructor(MyClass myClass) { 
      this.myClass = myClass; 
  } 
  

• 或者另一种方法是使用setter方法就像使用setter注入：

  public void setMyClass(MyClass myClas) { 
      this.myClass = myClass; 
  } 
  

有其他设计模式（如工厂或单件）使用静态方法并基于它们生成的输入参数不同的对象，你可以使用，但它完全不同于DI，可以帮助DI。

Answer 2

很多已经说和写这一点，但普遍的共识是，有一个全球性的“分解”（又名Service Locator pattern）是anti-pattern：

与服务定位器的问题是，它隐藏一个类' 依赖关系，导致运行时错误，而不是编译时错误， ，以及使代码更难以维护，因为它会变得不清楚，当你将引入一个突破性的变化。

而不是使用这个全局解析器，你应该使用oposite模式：依赖注入（DI）。使用DI，您可以将依赖关系注入到类中，而不是让类通过某个解析器请求依赖关系。最常见的 - 通常最好的方法是使用构造函数注入。这意味着某些类的构造函数在类sole constructor中定义了它作为构造函数参数所需的依赖关系。

类的构造函数应该只包含这个类直接使用的依赖项。类依赖关系所需的依赖关系不应暴露给该类，因为这只会不必要地增加代码的耦合性，并使代码难以测试，难以推理。

这样的结果是，应用程序中的非类将负责构建和请求它们的依赖关系。每个类将这个责任推到调用链上，导致在应用程序中有一个位置，靠近应用程序的启动路径，负责构建所有对象图：composition root。

构图根是您可以使用这样的解析器的地方，但这是可选的。