对于我的需求,我需要一个自定义范围(会话太大,而对于我的项目请求小).
想象一下,我请求guice提供一个类A的实例,它与许多其他类(组合)有直接和间接的依赖关系.
我的自定义提供程序能够提供用作所有相关类的构造函数参数的类的实例.
题：
>我真的必须在所有相关类的构造函数上放置一个@Inject(和我的自定义范围)注释,还是有一种方法,只需要在我请求的顶级类上添加这些注释,并且所有其他依赖项都是通过“请求”我的自定义范围来解析依赖类型的提供者？
如果这是真的,这将增加引入Guice的努力,因为我必须调整1000多个班级.在介绍guice的任何帮助和经验是赞赏.
解决方法
有理由认为,否则,它不能确定地告诉它应该注入什么以及在哪里.例如,类可能有多个构造函数,Guice需要一些选择一个不依赖于任何猜测的注入方式.你可以说“很好,我的课程只有一个构造函数,所以它不应该需要@Inject on”,但是当有人向类添加一个新的构造函数时会发生什么？然后,Guice不再有决定和申请的基础.另外,这一切都假定你只是在构造器注入.虽然构造函数注入一般是最好的选择,但Guice也允许注入方法(和字段),并且需要明确指定类的注入点的问题更强,因为大多数类将具有许多不是的方法用于注射,最多只有几个.
除了@ Inject在告知Guice中的重要性之外,它还作为一个类是如何被使用的文档 – 该类是应用程序的依赖注入有线基础结构的一部分.它也有助于在您的类中应用@Inject注释是一致的,即使当前在某些仅使用单个构造函数的情况下它绝对不需要.我还会注意到,如果标准Java注释比您对于Guice特定的注释更为可取,则可以在Guice 3.0中使用JSR-330的@ javax.inject.Inject注释.
我不太清楚你的意思是询问供应商的范围.范围通常不会自己创建对象;他们控制什么时候向未提供的提供者询问新实例的依赖关系以及如何控制该实例的范围.供应商是他们运营的一部分,当然,但我不知道这是什么意思.如果您有一些提供对象实例的自定义方式,那么提供者绑定和@Provides方法就是这样的方式,并且不需要在类本身上使用@Inject注释.
