我想介绍Guice 以用于现有的中型项目。
对于我的需求,我需要一个自定义范围(会话太大,而对我的项目的请求很小)。

想象一下,我请求向导为我提供一个A类的实例,该实例与以及许多其他类(组成)具有直接和间接的依赖关系。

我的自定义提供程序能够提供用作所有相关类的构造函数参数的类的实例。

问题:

  • 我是否真的必须在所有涉及的类的构造函数上放置@Inject(和我的自定义范围)批注,或者是否有一种方式,即guice 仅需要这些批注在我要求并在其上的顶级类上通过“询问”我的自定义范围为依赖类型的提供程序来解决所有其他依赖关系?

  • 如果是这样,这将增加引入Guice的工作量,因为我必须调整1000多个类。引入guice期间提供的任何帮助和经验都将受到赞赏。

    最佳答案

    首先,可以在没有任何地方放置@Inject注释的情况下使用Guice。 Guice支持Provider bindings@Provides methodsconstructor bindings,所有这些都允许您随意绑定类型。但是,对于其正常操作,它需要@Inject批注充当元数据,以告诉它类需要什么依赖项以及可以在哪里注入它们。

    这样做的原因是,否则,它无法确定性地告知应该注入什么以及在哪里注入。例如,类可能具有多个构造函数,而Guice需要某种不依赖任何猜测的选择方式来进行注入。您可以说“好吧,我的类只有一个构造函数,因此它不需要@Inject”,但是当有人向一个类添加新的构造函数时会发生什么呢?然后,Guice不再具有决定的依据,应用程序将中断。此外,所有这些都假设您仅在进行构造函数注入。通常,构造函数注入当然是最好的选择,但Guice也允许方法(和字段)的注入,并且在那里需要显式指定类的注入点的问题更加强烈,因为大多数类将具有许多未使用的方法用于注射,至多是几个。

    除了@Inject在告诉Guice方面的重要性外,它还用作说明如何使用类的文档-该类是应用程序依赖项注入有线基础结构的一部分。即使当前在仅使用单个构造函数的某些类上不是绝对必要的,这也有助于在类之间应用@Inject注释时保持一致。我还要注意,如果标准Java注释比Guice特定的注释更合适,则可以在Guice 3.0中使用JSR-330的@javax.inject.Inject注释。

    我不清楚您要问提供者的范围是什么意思。范围通常不会自己创建对象。它们控制何时向新实例询问依赖项的不受作用域的提供者,以及如何控制该实例的范围。当然,提供商是他们运作方式的一部分,但是我不确定这是否就是您的意思。如果您有一些自定义的方法来提供对象实例,则可以使用Provider绑定和@Provides方法,并且不需要在类本身上添加@Inject批注。

    07-24 09:38
    查看更多