HK2 代理与 javax.inject.Provider答案

【问题标题】：HK2 Proxy vs javax.inject.ProviderHK2 代理与 javax.inject.Provider
【发布时间】：2018-10-17 22:12:40
【问题描述】：

我有两个绑定到依赖注入器的单例服务（通过 Jersey）：

ResourceConfig.register(new AbstractBinder() {
    @Override
    protected void configure() {
        bind(Foo.class)
            .to(Foo.class)
            .in(Singleton.class);
        bind(Bar.class)
            .to(Bar.class)
            .in(Singleton.class);
    }
});

Foo 使用Bar，所以我可以简单地执行以下操作：

public class Foo {
    @javax.inject.Inject private Bar bar;
}

如果Foo 很少使用Bar，那么我可以推迟它的构造：

public class Foo {
    @javax.inject.Inject private javax.inject.Provider<Bar> bar;
}

我还读到一般建议使用Provider，因为它避免了这种急切的评估和循环依赖（尽管我尽量避免这些）。

但是让它成为代理呢？：

ResourceConfig.register(new AbstractBinder() {
    @Override
    protected void configure() {
        bind(Foo.class)
            .to(Foo.class)
            .in(Singleton.class)
            .proxy(true)
            .proxyForSameScope(true);
        bind(Bar.class)
            .to(Bar.class)
            .in(Singleton.class)
            .proxy(true)
            .proxyForSameScope(true);
    }
});

我是注射新手，所以不确定历史。对于两个不同的框架，它们实际上是相同的概念吗？

代理使代码看起来更漂亮，并将关注点推送给服务的创建者，而不是服务的用户（这可能是可取的，也可能不是可取的）。这与Provider相比有什么缺点吗？

注意这里唯一考虑的是单例服务。

【问题讨论】：

有时您别无选择。就像一些Jersey services 一样，它们并没有使它成为可代理的，所以你需要使用Provider。一般来说，如果可能的话，我认为代理是首选，只是因为它不那么冗长。但在某些情况下，代理是不可能的。至于（缺点）优点，除了不那么冗长之外，我真的想不出任何。

标签： dependency-injection jersey hk2

【解决方案1】：

这纯粹是一种意见，但出于您提到的大多数原因，我自己更喜欢代理。一般来说代理接口会更好，因为这样会使用 JDK 代理，但只要您的 Bar 类遵循代理规则，您仍然可以。

【讨论】：