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

如何解决CDI / WELD构造函数注入最佳实践

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

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

在这种情况下，ViewController是@Named + @ViewScoped，而所有其他bean（BeanA，BeanA1，BeanA2）都是{{ 1}}。 我们希望使用构造函数注入作为最佳实践。基于此，我们的类如下所示：

@SessionScoped

当将其作为WAR部署到Wildfly 20时，我们将出现以下错误/异常：

@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;
    }
}

由于我们不打算在集群中运行服务器，所以我不明白为什么我们需要一个非参数的构造函数（根本不需要序列化）。

添加"BeanA is not proxyable because it has no no-args constructor". 文件可以解决此问题，我们可以毫无问题地部署和运行该应用程序。 我问自己这是一个好习惯还是我们错过了什么？

解决方法

首先，最快的答案是：任何处于正常范围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中的bean都是normal scope。

如果您点击链接，您会发现CDI规范中这样做的原因不是（也许主要是）因为序列化，而是because of proxying。

您引用的属性是Weld-specific feature。如果您知道将继续使用Weld进行CDI实现，那么您当然可以继续使用此属性，但是严格来说，您的CDI应用程序现在不可移植。这可能对您无关紧要。

对于我发现的这个问题，最实用的解决方案是定义一个程序包专用的零参数构造函数，该构造函数是@Deprecated，它将字段设置为null。