为什么将豆工厂注入弹簧组件是正常的，而不是春豆？

Question

目前我看一个讲座(不是英语)，讲师声称将BeanFactory注入Spring内部组件是正常的。他的例子是：

public class PostProxyInvokerContextListener implements ApplicationListener<ContextRefreshedEvent> {
@Autowired
private ConfigurableListableBeanFactory factory;
@Override
public void onApplicationEvent(ContextRefreshedEvent event) {
...
}
}

他还说，将ApplicationContext或BeanFactory插入程序员创建的常规bean是不正常的。

我理解为什么我们应该避免使用常规豆子(紧密耦合)，但我不明白为什么该规则不适用于弹簧组件。

Answer 1

不同的 Spring项目使用 Spring 依赖项。如果我们知道我们不会放弃使用Spring框架，那么说我们不应该像ApplicationContext这样的Spring组件是不完全正确的。例如，如果我们知道我们正在开发的Web应用程序不会从Spring迁移到Struts(反正没有人这样做)，我们可以注入ApplicationContext。假设我们已经创建了一个自定义注释@ApplyControl它使用AOP应用一组检查(不同类型的检查)，我们可以使用ListableBeanFactory列出所有标记为@Control的类并将它们放在基于映射的注册表中，然后拉出要在建议中应用的控件。如果我们比较JPA和Hibernate，JPA标准为我们提供了一组由任何 ORM 实现的注释，因此在这种情况下，我们可以坚持使用 JPA 的注释，使我们的应用程序独立于 Hibernate 和任何此类实现。这与 Spring 的情况不同 - 我几乎没有见过有人将 Spring 与@Inject一起使用。也就是说，只有在没有其他更简单的方法来实现用例的情况下，才应该使用 Spring 提供的ListableBeanFactory或任何其他此类实现。