CDI / WELD 构造函数注入最佳实践

CDI / WELD Constructor injection best practices

在“单体”Jakarta-EE 8 应用程序中,我们希望将 JSF 与 CDI 结合使用。下图给出了视图和 类 如何相互依赖的示例:

JSF-View -> ViewController -> BeanA --> BeanA1
                                    \-> BeanA2
                                

在这种情况下,ViewController@Named + @ViewScoped,所有其他 bean(BeanABeanA1BeanA2)是@SessionScoped。 我们希望使用构造函数注入作为最佳实践。基于此,我们的 类 看起来像这样:

@Named
@ViewScoped
public class ViewController implements Serializable {

    private final BeanA bean;
    
    @Inject
    public ViewController(final BeanA bean) {
        this.bean = bean;
    }
}

@SessionScoped
public class BeanA implements Serializable {

    private final BeanA1 bean1;
    
    private final BeanA2 bean2;
    
    @Inject
    public BeanA(final BeanA1 bean1, final BeanA2 bean2) {
        this.bean1 = bean1;
        this.bean2 = bean2;
    }
}

将此作为 WAR 部署到 Wildfly 20 时,我们以以下错误/异常结束:

"BeanA is not proxyable because it has no no-args constructor".

因为我们不打算 运行 集群中的服务器,所以我不明白为什么我们需要一个非参数构造函数(根本不需要序列化)。

添加 META-INF/org.jboss.weld.enableUnsafeProxies 文件解决了问题,我们可以毫无错误地部署和 运行 应用程序。 我问自己这是一个好的做法还是我们遗漏了什么?

首先,最快的答案:正常范围内的任何 bean must have a non-private, zero-argument constructor. In addition, such classes must not be final and must not have non-private, virtual final methods. @SessionScoped is a normal scope

如果您遵循 link,您会发现在 CDI 规范中这样做的原因不是(也许主要)是因为序列化,而是 because of proxying.

您所指的属性是Weld-specific feature。如果您知道您将继续使用 Weld 进行 CDI 实施,那么您当然可以继续使用此 属性,但严格来说,您的 CDI 应用程序现在是 non-portable。这对您来说可能重要,也可能不重要。

我发现这个问题的最实用的 real-world 解决方案是定义一个 package-private 零参数构造函数,即 @Deprecated 将字段设置为 null.