java - 注入(inject)的 bean 什么时候真正初始化？

Question

我的代码库中有以下场景:

//this bean, which will be injected,
//is not annotated
public class HelperUtil {
   //only default constructor with no args

   public void doThis(String _in) {
      //...
   }

   public void doThat() {
      //...
   }
}

在下面的类中我们进行注入(inject):

@Named
@Stateless
public class BusinessManager {

    @PersistenceContext(unitName = "default")
    private EntityManager em;

    @Inject
    private HelperUtil helperUtil ;

    //...
}

Q1:要注入(inject)的HelperUtil实例什么时候调用默认构造函数真正初始化？当应用程序服务器(在我的例子中是 JBoss)启动时，它被注入(inject)的第一个客户端(如 BusinessManager)被实例化(并且那个将被初始化)时是否完成由容器，因为它被注释为 @Stateless)?

Q2:在上面的展示中，只要容器以外的客户端都没有请求实例，HelperUtil 是否会保持为单例直接调用构造函数而不是通过DI获取实例？

问题 3: 在这种情况下使用 DI 和 @Inject 与直接调用构造函数相比有什么优势 (HelperUtil helper = new HelperUtil() ;)?

Answer 1

视情况而定，但您可以控制这些事件来执行一些代码，例如:如果您需要在应用程序启动时执行您的 bean，您需要向您的 bean 添加 @Startup 注释。如果您需要在不访问其他注入(inject)资源的情况下初始化您的 bean，您可以使用普通构造函数。如果您需要在初始化 bean 时执行某些方法，请在方法中使用 @PostConstruct 注释。

您需要记住，创建取决于 bean 的范围，在您的情况下，这是一个无状态的 bean，如果某个客户端注入(inject)它并且没有其他实例可用，则将创建 bean，如果是单例，则bean 将只创建一次，一般来说，bean 将在需要时创建(单例 bean 初始化直到第一个客户端使用它，或者在启动时使用注释)

编辑:对于第三个问题，优点是如果您在 HelperUtil 中使用资源或其他 bean，它们将使用适当的值进行初始化，例如，如果您使用实体管理器或其他你的助手里面的 bean 。如果您的助手将只处理静态方法或其他简单实用程序之类的事情，那么您是对的，优势是没有，您可以像静态助手类一样简单地管理，但是如果您需要 EE 资源，则需要按顺序管理 bean加载所有注入(inject)和资源

编辑 2:经过多年编程并在 Java 和 C# Core 中使用依赖注入(inject)，我可以补充:问题 3 非常开放，使用 DI 将允许您的代码:

• 减少耦合，如果您更改构造函数，则必须搜索所有 new ObjectModified(oldParams) 以添加新参数
• 更容易测试，因为你可以注入(inject)“假对象”作为依赖，避免加载所有系统和准备测试状态的需要，例如，如果你想检查一些依赖于当前的代码小时，您可以在测试模式下连接一个假供应商，以始终提供相同的时间或某个顺序
• 避免循环依赖，其中类 A 依赖于 B，类 B 依赖于 A，通常情况下这更复杂，例如

ClasssA -> ClasssB -> ClasssC -> ClasssA

当存在这种依赖关系时，您可以开始修改，然后修改使用它的类，依此类推...直到不知何故，您发现自己正在修改与以前相同的类!，所以您开始循环，因为对象之间的通信路径很复杂。当您使用 DI 时，可以及早检测到这种循环，因此您可以重新考虑您的架构以避免这种生产力黑洞

DI 是保持大型项目可维护性的非常强大的工具，现在存在于很多环境和框架中，因为它非常有用，如果这仍然不能说服你，你可以尝试在 Spring boot、PlayFramework 中启动一个项目， Net Core、Java EE、Ruby on Rails ....以及许多其他已将此作为正常流程并构建中型应用程序的人，然后尝试不使用 DI