辅助注射什么时候有用？

Question

我目前正在我的应用程序中使用Guice。然而，我发现自己大多使用辅助注入，因为有一个注入对象链，它们都依赖于程序的输入。因此几乎所有的东西都是辅助注射的。

例如，A需要B，B需要c，c需要Z，Z需要来自命令行的输入。最后我感觉一切都将被辅助注射。因此，鉴于我坚持使用它，我想确定我使用它是正确的。

我个人觉得写我自己的工厂也一样好。此外，除了同样的优点之外，我还可以进一步将我所讨论的对象的创建限制在这些工厂。

因此，我的问题是，使用辅助注射到底有多有用，这只是同时进行辅助和非辅助的想法吗？如果像我的情况一样，你只有辅助参数呢？

他们在组织辅助注射方面一定有所收获。我就是看不出来。

如果有人能在这里启发我，我将不胜感激，

非常感谢

PS：

我的依赖是这样的:

我有一个InfrastructureService，它需要一个KnowledgeBaseService，反过来又需要一个ConFigDataObject。我的configDataObject包含来自程序输入的信息。configDataObject在对这些输入进行一些验证和处理后存储这些信息。例如，可以向它提供一个表示文件路径的字符串，它将验证它是存在的文件，并使用getter方法将该文件返回给它的使用者。其他内容可能是URLName到真实的URL对象，等等。

这里重要的一点是下图：基础设施服务-

因此，基础设施服务只能与以正确的输入文件，URL，工作文件夹等启动的知识库服务一起使用。它与 configDataObject 一起提供给它，该对象从程序的输入中接收它们并存储它们的处理版本。

因此，到目前为止，我所做的是让一个assistedFactory创建知识库服务。它将ConfigDataObject作为参数。configDataObject是使用factoryMethod（Scala Companion Object）创建的。最后，还为InfrastructureService创建了一个assistedFactory，它将KnowledgeBaseService作为其创建方法的参数。

正如你所猜测的，一切都是预先创建的，而且是手动创建的。我觉得很奇怪。

Answer 1

这是我所做的，最终以一种更优雅的方式解决了这个问题，而不是由于应用程序的参数而使用不必要的辅助注入链。

也就是说，如果像我的情况一样，您的数据来自命令行，那么我认为正确的方法是将输入数据结构的类型绑定到从命令行获得的实例输入结构：

object MyApp extends App {

  val config = ConfigData(args(0))

  val injector = Guice.createInjector(module(config))
  val service = injector.getInstance(classOf[InfrastructureService])

  println("The service name is:" + service.kbService.config.configName)

}


case class module(config: ConfigData) extends AbstractModule {
  def configure(): Unit = {
    bind(classOf[ConfigData]).toInstance(config)
  }
}

case class ConfigData(val configName: String)

class KbService @Inject() (val config: ConfigData)

class InfrastructureService @Inject() (val kbService: KbService)

我相信这里的关键是提醒自己，模块可以用任何认为必要的输入数据进行参数化

Answer 2

看起来您过度使用了“依赖”的概念。您应该首先将封装用户输入（实际上是任何数据）的类与包含业务逻辑的类分开，然后您应该通过方法传递这些数据，而不是通过注入，因为用户输入不是依赖项。

这样，您几乎永远不需要辅助注入，因为您可以使用new直接创建“数据”类（这是可以的，因为它们没有依赖关系），并且“行为”类可以通过构造函数以标准方式相互注入。然后，“行为”类将发挥作用，传递“数据”类的对象，而不是将它们作为依赖项。您将看到辅助注入的需求消失了，您的程序变得更加简单易懂。

例如，而不是像下面这样：

public class OtherDependency {
    private final int s;

    @Inject
    OtherDependency(@Assisted int s, ...) {
        this.s = s;
        ...
    }

    public void doWork() { /* use s */ ... }
}

public class SumService {
    private final int x1;
    private final int x2;
    private final OtherDependencyFactory depFactory;

    @Inject
    SumService(@Assisted int x1, @Assisted int x2, OtherDependencyFactory depFactory) {
        this.x1 = x1;
        this.x2 = x2;
        this.depFactory = depFactory;
    }

    public void doWork() {
        int s = x1 + x2;

        OtherDependency dep = depFactory.create(s);
        dep.doWork();
    }
}

public class EntryPoint {
    private final SumServiceFactory sumServiceFactory;

    @Inject
    EntryPoint(SumServiceFactory sumServiceFactory) {
        this.sumServiceFactory = sumServiceFactory;
    }

    public void start() {
        Scanner sc = new Scanner(System.in);
        int x1 = sc.nextInt();
        int x2 = sc.nextInt();

        SumService sumService = sumServiceFactory.create(x1, x2);
        sumService.doWork();
    }
}

（很明显，我对你的程序不太了解，但当我看到“首先需要用户输入的依赖链”时，我就想到了这一点）

您应该制作类似于

public class OtherDependency {
    @Inject
    OtherDependency(...) {
        ...
    }

    public void doWork(int s) { /* use s */ ... }
}

public class SumService {
    private final OtherDependency dep;

    @Inject
    SumService(OtherDependency dep) {
        this.dep = dep;
    }

    public void doWork(int x1, int x2) {
        int s = x1 + x2;
        dep.doWork(s);
    }
}

public class EntryPoint {
    private final SumService sumService;

    @Inject
    EntryPoint(SumService sumService) {
        this.sumService = sumService;
    }

    public void start() {
        Scanner sc = new Scanner(System.in);
        int x1 = sc.nextInt();
        int x2 = sc.nextInt();

        sumService.doWork(x1, x2);
    }
}

所有用户输入都通过方法参数从类传递到类，这些类本身是无状态的，只是正常注入。完全不需要使用辅助注射。

更新

我看了你的更新。做你想做的事情有多种可能性，复杂程度各不相同。

首先，最简单的一种方法(我认为是这种情况下最好的方法)是通过方法调用传递输入数据。我不明白你的建筑怎么会禁止这样做。只需让< code > knowledge base service 上需要此数据的所有方法接受它，并从< code > infra structureservice 传递它。这里不需要辅助注射。

其次，您可以在创建注入器之前获取用户输入，然后执行 toInstance（） 绑定。这取决于实际的体系结构，因此可能无法正常工作。我相信这是最简单的方法，它提供了非常简单和灵活的结构。

第三，您可以使用提供程序。为您的ConfiDataObject创建一个提供程序，它要求用户输入并创建相应的实例，然后在单例范围内将ConfiDataObject绑定到它。如果用户输入不失败，这将有效，因为您不应该从提供程序抛出异常。如果您需要用户输入验证，请使用抛出提供程序扩展。用户输入将在第一次访问提供程序时触发，然后由于其范围，结果将被缓存。

可能还有其他方法，但这些是我能想到的。