对我来说，选择BeanFactory而不是ApplicationContext的主要区别似乎是ApplicationContext将预先实例化所有的bean。来自Spring文档:

Spring sets properties and resolves dependencies as late as possible, when the bean is actually created. This means that a Spring container which has loaded correctly can later generate an exception when you request an object if there is a problem creating that object or one of its dependencies. For example, the bean throws an exception as a result of a missing or invalid property. This potentially delayed visibility of some configuration issues is why ApplicationContext implementations by default pre-instantiate singleton beans. At the cost of some upfront time and memory to create these beans before they are actually needed, you discover configuration issues when the ApplicationContext is created, not later. You can still override this default behavior so that singleton beans will lazy-initialize, rather than be pre-instantiated.

考虑到这一点，我最初选择BeanFactory用于集成/性能测试，因为我不想加载整个应用程序来测试孤立的bean。但是——如果我说错了，有人会纠正我——BeanFactory不支持类路径XML配置。因此，BeanFactory和ApplicationContext都提供了我想要的关键特性，但两者都没有。

据我所知，文档中关于覆盖默认实例化行为的说明发生在配置中，而且它是每个bean的，所以我不能在XML文件中设置“lazy-init”属性，否则我就不得不维护一个版本用于测试，另一个版本用于部署。

我最终所做的是扩展ClassPathXmlApplicationContext以惰性加载bean以在测试中使用，如下所示:

public class LazyLoadingXmlApplicationContext extends ClassPathXmlApplicationContext {

    public LazyLoadingXmlApplicationContext(String[] configLocations) {
        super(configLocations);
    }

    /**
     * Upon loading bean definitions, force beans to be lazy-initialized.
     * @see org.springframework.context.support.AbstractXmlApplicationContext#loadBeanDefinitions(org.springframework.beans.factory.xml.XmlBeanDefinitionReader)
     */

    @Override
    protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws IOException {
        super.loadBeanDefinitions(reader);
        for (String name: reader.getBeanFactory().getBeanDefinitionNames()) {
            AbstractBeanDefinition beanDefinition = (AbstractBeanDefinition) reader.getBeanFactory().getBeanDefinition(name);
            beanDefinition.setLazyInit(true);
        }
    }

}

a. bean工厂和应用程序上下文之间的一个区别是前者只在调用getBean()方法时实例化bean，而ApplicationContext在容器启动时实例化单例bean，它不等待getBean被调用。

b。

ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");

or

ApplicationContext context = new ClassPathXmlApplicationContext{"spring_dao.xml","spring_service.xml};

您可以根据项目需求使用一个或多个xml文件。我在这里使用了两个xml文件，即一个用于服务类的配置细节，另一个用于dao类。这里ClassPathXmlApplicationContext是ApplicationContext的子。

c. BeanFactory Container是基本容器，它只能创建对象和注入依赖项。但我们不能附加其他服务，如安全、事务、消息等，以提供我们必须使用ApplicationContext容器的所有服务。

d. BeanFactory不提供国际化支持，即i18n，但ApplicationContext提供了国际化支持。

e. BeanFactory容器不支持自动扫描(支持基于注释的依赖注入)特性，但ApplicationContext容器支持。

f.直到请求时间，Beanfactory容器才会创建bean对象。这意味着Beanfactory容器会懒惰地装载bean。而ApplicationContext容器只在加载时创建单例bean的对象。这意味着有早期装载。

Beanfactory容器只支持bean的两个作用域(单例和原型)。但是ApplicationContext容器支持所有的bean范围。

对我来说，选择BeanFactory而不是ApplicationContext的主要区别似乎是ApplicationContext将预先实例化所有的bean。来自Spring文档:

Spring sets properties and resolves dependencies as late as possible, when the bean is actually created. This means that a Spring container which has loaded correctly can later generate an exception when you request an object if there is a problem creating that object or one of its dependencies. For example, the bean throws an exception as a result of a missing or invalid property. This potentially delayed visibility of some configuration issues is why ApplicationContext implementations by default pre-instantiate singleton beans. At the cost of some upfront time and memory to create these beans before they are actually needed, you discover configuration issues when the ApplicationContext is created, not later. You can still override this default behavior so that singleton beans will lazy-initialize, rather than be pre-instantiated.

考虑到这一点，我最初选择BeanFactory用于集成/性能测试，因为我不想加载整个应用程序来测试孤立的bean。但是——如果我说错了，有人会纠正我——BeanFactory不支持类路径XML配置。因此，BeanFactory和ApplicationContext都提供了我想要的关键特性，但两者都没有。

据我所知，文档中关于覆盖默认实例化行为的说明发生在配置中，而且它是每个bean的，所以我不能在XML文件中设置“lazy-init”属性，否则我就不得不维护一个版本用于测试，另一个版本用于部署。

我最终所做的是扩展ClassPathXmlApplicationContext以惰性加载bean以在测试中使用，如下所示:

public class LazyLoadingXmlApplicationContext extends ClassPathXmlApplicationContext {

    public LazyLoadingXmlApplicationContext(String[] configLocations) {
        super(configLocations);
    }

    /**
     * Upon loading bean definitions, force beans to be lazy-initialized.
     * @see org.springframework.context.support.AbstractXmlApplicationContext#loadBeanDefinitions(org.springframework.beans.factory.xml.XmlBeanDefinitionReader)
     */

    @Override
    protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws IOException {
        super.loadBeanDefinitions(reader);
        for (String name: reader.getBeanFactory().getBeanDefinitionNames()) {
            AbstractBeanDefinition beanDefinition = (AbstractBeanDefinition) reader.getBeanFactory().getBeanDefinition(name);
            beanDefinition.setLazyInit(true);
        }
    }

}

ApplicationContext: 它加载spring配置文件中配置的spring bean，并在CONTAINER启动时管理spring bean的生命周期。它不会等到getBean("springbeanref")被调用。

BeanFactory 它加载spring配置文件中配置的springbean，在调用getBean("springbeanref")时管理springbean的生命周期。因此，当我们在springbean生命周期开始时调用getBean(“springbeanref”)时。

我认为值得一提的是，从Spring 3开始，如果您想创建一个工厂，您还可以使用@configuration注释结合适当的@scope

@Configuration
public class MyFactory {

    @Bean
    @Scope("prototype")
    public MyClass create() {
        return new MyClass();
    }
}

使用@ComponentScan注释或xml配置，Spring容器应该可以看到您的工厂

春豆范围文章从贝龙网站

spring文档在这方面做得很好:3.8.1。BeanFactory还是ApplicationContext? 他们有一个比较表，我将发布一个片段:

Bean工厂

Bean实例化/布线

应用程序上下文

Bean实例化/布线 自动BeanPostProcessor注册 自动BeanFactoryPostProcessor注册 方便的MessageSource访问(用于i18n) ApplicationEvent出版

因此，如果您需要应用程序上下文端显示的任何点，您应该使用ApplicationContext。