Java BeanFactoryAware VS.@Autowired-自动连接BeanFactory是个坏主意吗？

或者，以另一种方式—更好的方法是使用自动布线：

@Autowired
private BeanFactory beanFactory;

或实施

BeanFactoryAware

：

@Configuration
public class MyConfigurationClass implements BeanFactoryAware {

    private BeanFactory beanFactory;

    @Override
    public void setBeanFactory(final BeanFactory beanFactory) throws BeansException {
        this.beanFactory = beanFactory;
    }
}

---

有什么区别吗（除了设置BeanFactory实例的阶段）？

想象一下以下情况： 在一个上下文中有两个BeanFactory，其中一个具有-注释

假设第二个BeanFactory（没有-注释）创建了类的实例

在这种情况下，您将有不同之处：

---

当第一种方法将@Autowire注释的BeanFactory时，第二种方法将连接创建实例的BeanFactory。

Peter，谢谢你的回答，它提出了一个很好的观点，我不确定是否每个人都知道这一点。我没有），但除了你提到的，还有没有关于哪种方法更好（如果有的话）的常见建议，用更抽象的术语来说，比如好/坏的风格，或者潜在的代码气味？另外，很抱歉回复得太晚-我有一段时间没有上网限制。@Nick这取决于你对

BeanFactory

的进一步操作。在上面提供的类中，该字段从未使用过！如果只需要该字段来检查上下文中是否存在

BeanFactory

-实例，那么最好使用

@DependsOn（BeanFactory.class）

作为类注释（靠近

@Configuration

）。你提供的代码有气味吗？一点！看，我遇到过这样一种情况，我们将静态配置部分实现为AppConfig Java类，将XML配置部分放在文件系统的某个地方。因此，我们有两个

BeanFactory

s，每10秒扫描一次XML配置以进行修改。如果XML配置中有修改，并且文件格式正确，则整个上下文已关闭并再次重新启动。这是一个巨大的配置类，用几十种方法初始化bean。每个初始化的bean都需要一些其他bean，几乎每个方法都需要不同的bean，并且通常类似于5-6个bean依赖项。因此，我们决定使用工厂来避免配置的膨胀。所以“beanFactory.getBean（“someBean”）；”是这里唯一的用法。@Nick请在问题中添加一种方法（具有大量依赖项），我认为您的问题有xy问题。