BeanFactory против ApplicationContext

Документы Spring отлично подходят для этого: 3.8.1. BeanFactory или ApplicationContext?. У них есть таблица со сравнением, выложу отрывок:

Фабрика фасоли

• Создание экземпляра бина / подключение

Контекст приложения

• Создание экземпляра компонента / подключение
• Автоматическая регистрация BeanPostProcessor
• Автоматическая регистрация BeanFactoryPostProcessor
• Удобный доступ к источнику сообщений (для i18n)
• Публикация ApplicationEvent

Поэтому, если вам нужна какая-либо из точек, представленных на стороне контекста приложения, вы должны использовать ApplicationContext.

Чтобы добавить к тому, что ответил Мигель Пинг, вот еще один раздел из документации, который также отвечает на это:

Short version: use an ApplicationContext unless you have a really good reason for not doing so. For those of you that are looking for slightly more depth as to the 'but why' of the above recommendation, keep reading.

(отправляем это всем будущим новичкам Spring, которые могут прочитать этот вопрос)

По большей части ApplicationContext предпочтительнее, если вам не нужно экономить ресурсы, как в мобильном приложении.

Я не уверен в зависимости от формата XML, но уверен, что наиболее распространенными реализациями ApplicationContext являются XML, такие как ClassPathXmlApplicationContext, XmlWebApplicationContext и FileSystemXmlApplicationContext. Это единственные три, которые я когда-либо использовал.

Если вы разрабатываете веб-приложение, можно с уверенностью сказать, что вам нужно использовать XmlWebApplicationContext.

Если вы хотите, чтобы ваши bean-компоненты знали о Spring, вы можете заставить их реализовать для этого BeanFactoryAware и / или ApplicationContextAware, поэтому вы можете использовать BeanFactory или ApplicationContext и выбрать, какой интерфейс реализовать.

Я думаю, что лучше всегда использовать ApplicationContext, если только вы не находитесь в мобильной среде, как уже сказал кто-то другой. ApplicationContext имеет больше функциональных возможностей, и вы определенно хотите использовать такие PostProcessor, как RequiredAnnotationBeanPostProcessor, AutowiredAnnotationBeanPostProcessor и CommonAnnotationBeanPostProcessor, которые помогут вам упростить ваши файлы конфигурации Spring, и вы можете использовать аннотации, такие как @Required, @PostConstruct, и т. д.

Даже если вы не используете все то, что предлагает ApplicationContext, все равно лучше использовать его, а затем, если вы решите использовать некоторые ресурсы, такие как сообщения или постпроцессоры, или другую схему для добавления транзакционных советов и т. д., Вы уже будет ApplicationContext и не нужно будет изменять какой-либо код.

Если вы пишете автономное приложение, загрузите ApplicationContext в свой основной метод, используя ClassPathXmlApplicationContext, получите главный компонент и вызовите его run () (или любой другой метод) для запуска вашего приложения. Если вы пишете веб-приложение, используйте ContextLoaderListener в web.xml, чтобы он создавал ApplicationContext, и вы могли позже получить его из ServletContext, независимо от того, используете ли вы JSP, JSF, JSTL, struts, Tapestry и т. д.

Кроме того, помните, что вы можете использовать несколько файлов конфигурации Spring, и вы можете либо создать ApplicationContext, перечислив все файлы в конструкторе (или перечислив их в параметре context для ContextLoaderListener), либо вы можете просто загрузить основной файл конфигурации, который имеет операторы импорта. Вы можете импортировать файл конфигурации Spring в другой файл конфигурации Spring с помощью <import resource = "otherfile.xml" />, который очень полезен, когда вы программно создаете ApplicationContext в основном методе и загружаете только один файл конфигурации Spring.

1. ApplicationContext более предпочтителен, чем BeanFactory

2. В новых версиях Spring BeanFactory заменен на ApplicationContext. Но все же BeanFactory существует для обратной совместимости.

3. ApplicationContext extends BeanFactory и имеет следующие преимущества
   • поддерживает интернационализацию текстовых сообщений
   • поддерживает публикацию событий для зарегистрированных слушателей
   • доступ к ресурсам, таким как URL-адреса и файлы

На мой взгляд, основное различие в выборе 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 для использования в тестах интеграции / производительности, поскольку я не хотел загружать все приложение для тестирования изолированных компонентов. Однако - и кто-нибудь поправит меня, если я ошибаюсь - BeanFactory не поддерживает XML-конфигурацию classpath. Итак, BeanFactory и ApplicationContext обеспечивают важную функцию, которую я хотел, но ни то, ни другое не помогло.

Насколько я могу судить, примечание в документации о переопределении поведения создания экземпляра по умолчанию имеет место в конфигурации, и это для каждого bean-компонента, поэтому я не могу просто установить атрибут "lazy-init" в XML-файле или я застрял в поддержании его версии для тестирования и одной для развертывания.

В итоге я расширил ClassPathXmlApplicationContext для ленивой загрузки beans для использования в таких тестах:

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

}

Обратитесь к этому документу из Spring Docs:

http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/beans.html#context-introduction-ctx-vs-beanfactory

5.15.1 BeanFactory или ApplicationContext?

Используйте ApplicationContext, если у вас нет веской причины этого не делать.

Поскольку ApplicationContext включает в себя все функции BeanFactory, его обычно рекомендуется использовать вместо BeanFactory, за исключением нескольких ситуаций, например, в Applet, где потребление памяти может быть критическим и несколько дополнительных килобайт могут иметь значение. Однако для большинства типичных корпоративных приложений и систем ApplicationContext - это то, что вы захотите использовать. Spring 2.0 и более поздние версии активно используют точку расширения BeanPostProcessor (для выполнения проксирования и т. д.). Если вы используете только простой BeanFactory, значительная поддержка, такая как транзакции и АОП, не вступит в силу, по крайней мере, без некоторых дополнительных шагов с вашей стороны. Эта ситуация может сбивать с толку, потому что на самом деле с конфигурацией все в порядке.

ApplicationContext: Он загружает компоненты Spring, настроенные в файле конфигурации Spring, и управляет жизненным циклом компонента Spring как и WHEN CONTAINER STARTS. Он не будет ждать вызова getBean ("springbeanref").

BeanFactory Он загружает компоненты Spring, настроенные в файле конфигурации Spring, управляет жизненным циклом компонента Spring, когда мы вызываем getBean ("springbeanref"). Таким образом, когда мы вызываем getBean ("springbeanref") во время запуска жизненного цикла компонента Spring.

ApplicationContext - это старший брат BeanFactory, и это все, что предоставляет BeanFactory, а также многое другое.

В дополнение к стандартным возможностям жизненного цикла org.springframework.beans.factory.BeanFactory, реализации ApplicationContext обнаруживают и вызывать компоненты ApplicationContextAware, а также компоненты ResourceLoaderAware, ApplicationEventPublisherAware и MessageSourceAware.

Матрица функций Bean Factory и контекст приложения получено из весенних документов

_{Screenshot of features of BeanFacotry and ApplicationContext}

BeanFactory и ApplicationContext - оба способа получить beans из вашего весеннего контейнера МОК, но все же есть некоторая разница.

BeanFactory - это фактический контейнер, который создает, настраивает и управляет несколькими компонентами. Эти bean-компоненты обычно взаимодействуют друг с другом и, следовательно, имеют зависимости между собой. Эти зависимости отражаются в данных конфигурации, используемых BeanFactory.

BeanFactory и ApplicationContext оба являются интерфейсами Java, а ApplicationContext расширяет BeanFactory. Оба они конфигурируются с использованием файлов конфигурации XML. Короче говоря, BeanFactory предоставляет базовые функции инверсии управления (IoC) и внедрения зависимостей (DI), в то время как ApplicationContext предоставляет функции передовой.

BeanFactory представлен интерфейсом «org.springframework.beans.factory», где BeanFactory, для которого существует несколько реализаций.

ClassPathResource resource = new ClassPathResource("appConfig.xml");
XmlBeanFactory factory = new XmlBeanFactory(resource);

РАЗНИЦА

1. BeanFactory создает экземпляр bean-компонента при вызове метода getBean (), в то время как ApplicationContext создает экземпляр bean-компонента Singleton при запуске контейнера. Он не ждет вызова getBean ().

2. BeanFactory не поддерживает интернационализацию, но ApplicationContext обеспечивает ее поддержку.

3. Еще одно различие между BeanFactory и ApplicationContext - это возможность публиковать событие в bean-компонентах, которые зарегистрированы как прослушиватель.

4. Одна из популярных реализаций интерфейса BeanFactory - XMLBeanFactory, а одна из популярных реализаций интерфейса ApplicationContext - ClassPathXmlApplicationContext.

5. Если вы используете автоматическое подключение и используете BeanFactory, вам необходимо зарегистрировать AutoWiredBeanPostProcessor с помощью API, который вы можете настроить в XML, если вы используете ApplicationContext. Таким образом, BeanFactory подходит для тестирования и непроизводственного использования, но ApplicationContext является более многофункциональной реализацией контейнера и его следует отдавать предпочтение перед BeanFactory.

6. BeanFactory по умолчанию поддерживает загрузку Ленивый, а ApplicationContext по умолчанию поддерживает загрузку Агрессивный.

В принципе, мы можем создать объект-контейнер Spring двумя способами.

1. используя BeanFactory.
2. используя ApplicationContext.

оба интерфейса,

используя классы реализации, мы можем создать объект для контейнера Spring

приходя к различиям

BeanFactory:

1. Не поддерживает внедрение зависимостей на основе аннотаций.

2. Не поддерживает I18N.

3. По умолчанию он поддерживает ленивую загрузку.

4. он не позволяет настраивать несколько файлов конфигурации.

пример: BeanFactory context = new XmlBeanFactory (новый ресурс ("applicationContext.xml"));

ApplicationContext

1. Поддержка зависимостей на основе аннотаций Injection.-@Autowired, @PreDestroy

2. Поддержка I18N

3. По умолчанию поддерживает агрессивную загрузку.

4. Это позволяет настроить несколько файлов конфигурации.

пример:
ApplicationContext context = новый ClasspathXmlApplicationContext ("applicationContext.xml");

Spring provides two kinds of IOC container, one is XMLBeanFactory and other is ApplicationContext.

+---------------------------------------+-----------------+--------------------------------+
|                                       | BeanFactory     |       ApplicationContext       |
+---------------------------------------+-----------------+--------------------------------+
| Annotation support                    | No              | Yes                            |
| BeanPostProcessor Registration        | Manual          | Automatic                      |
| implementation                        | XMLBeanFactory  | ClassPath/FileSystem/WebXmlApplicationContext|
| internationalization                  | No              | Yes                            |
| Enterprise services                   | No              | Yes                            |
| ApplicationEvent publication          | No              | Yes                            |
+---------------------------------------+-----------------+--------------------------------+

• FileSystemXmlApplicationContext Компоненты загружены по полному пути.
• ClassPathXmlApplicationContext Beans, загруженные через CLASSPATH
• Компоненты XMLWebApplicationContext и AnnotationConfigWebApplicationContext загружаются через контекст веб-приложения.
• AnnotationConfigApplicationContext Загрузка компонентов Spring из конфигурации на основе аннотаций.

пример:

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeansConfiguration.class);

• ApplicationContext - это контейнер, инициализированный ContextLoaderListener или ContextLoaderServlet, определенным в web.xml, и ContextLoaderPlugin, определенным в struts-config.xml.

Примечание: XmlBeanFactory является устарел с Spring 3.1 в пользу DefaultListableBeanFactory и XmlBeanDefinitionReader.

В сценарии реального времени разница между контейнером Spring IOC Core (BeanFactory) и расширенным контейнером J2EE (ApplicationContext) заключается в следующем.

1. BeanFactory будет создавать объекты для bean-компонентов (то есть для классов POJO), упомянутых в файле spring.xml (<bean></bean>), только когда вы вызываете метод .getBean (), но тогда как ApplicationContext создает объекты для всех bean-компонентов (<bean></bean>, если его область действия не упоминается явно как «Прототип»), настроенный в файле spring.xml при загрузке самого файла spring.xml.

2. BeanFactory: (Ленивый контейнер, потому что он создает объекты для bean-компонентов только тогда, когда вы явно вызываете из пользовательского / основного класса)

   /*
    * Using core Container - Lazy container - Because it creates the bean objects On-Demand
    */
   //creating a resource
   Resource r = (Resource) new ClassPathResource("com.spring.resources/spring.xml");
   //creating BeanFactory 
   BeanFactory factory=new XmlBeanFactory(r);
   
   //Getting the bean for the POJO class "HelloWorld.java"
   HelloWorld worldObj1 = (HelloWorld) factory.getBean("test");
   

   ApplicationContext: (Стремительный контейнер из-за создания объектов всех одноэлементных bean-компонентов при загрузке самого файла spring.xml)

   ApplicationContext context = new ClassPathXmlApplicationContext("com/ioc/constructorDI/resources/spring.xml");
   

3. Технически рекомендуется использовать ApplicationContext, потому что в приложениях реального времени объекты bean-компонентов будут созданы во время запуска приложения на самом сервере. Это сокращает время ответа на запрос пользователя, поскольку объекты уже доступны для ответа.

а. Одно различие между фабрикой компонентов и контекстом приложения состоит в том, что первый экземпляр компонента создается только при вызове метода getBean (), в то время как ApplicationContext создает экземпляр компонента Singleton при запуске контейнера. Он не ждет вызова getBean.

б.

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

или же

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

Вы можете использовать один или несколько XML-файлов в зависимости от требований вашего проекта. Поскольку я здесь использую два файла xml, то есть один для деталей конфигурации для классов обслуживания, другой для классов dao. Здесь ClassPathXmlApplicationContext является дочерним по отношению к ApplicationContext.

c. BeanFactory Container - это базовый контейнер, он может только создавать объекты и вводить зависимости. Но мы не можем присоединить другие службы, такие как безопасность, транзакции, обмен сообщениями и т. д., Для предоставления всех служб, которые у нас есть, для использования ApplicationContext Container.

d. BeanFactory не поддерживает интернационализацию, то есть i18n, но ApplicationContext поддерживает ее.

е. Контейнер BeanFactory не поддерживает функцию автоматического сканирования (поддержка внедрения зависимостей на основе аннотаций), но контейнер ApplicationContext поддерживает.

f. Контейнер Beanfactory не будет создавать объект bean до времени запроса. Это означает, что Beanfactory Container лениво загружает бобы. В то время как ApplicationContext Container создает объекты bean-компонента Singleton только во время загрузки. Значит, идет ранняя загрузка.

грамм. Контейнер Beanfactory поддерживает только две области (singleton и prototype) bean-компонентов. Но контейнер ApplicationContext поддерживает всю область действия bean-компонентов.

Разница между BeanFactory и ApplicationContext заключается в следующем:

1. BeanFactory использует отложенную инициализацию. но ApplicationContext использует активную инициализацию. В случае BeanFactory, bean-компонент создается при вызове метода getBeans (), но bean-компонент создается заранее в случае ApplicationContext, когда создается объект ApplicationContext.
2. BeanFactory явно предоставляет объект ресурса с использованием синтаксиса но ApplicationContext создает объекты ресурсов и управляет ими самостоятельно.
3. BeanFactory не поддерживает интернационализацию. но ApplicationContext поддерживает интернационализацию.
4. В BeanFactory внедрение зависимостей на основе аннотаций не поддерживается. но Внедрение зависимостей на основе аннотаций поддерживается в ApplicationContext.

Использование BeanFactory:

BeanFactory beanfactory = new XMLBeanFactory(new FileSystemResource("spring.xml"));
 Triangle triangle =(Triangle)beanFactory.getBean("triangle");

Использование ApplicationContext:

ApplicationContext context = new ClassPathXMLApplicationContext("spring.xml")
Triangle triangle =(Triangle)context.getBean("triangle");

Я думаю, стоит упомянуть, что начиная с Spring 3, если вы хотите создать фабрику, вы также можете использовать аннотацию @configuration в сочетании с правильным @scope

@Configuration
public class MyFactory {

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

Ваша фабрика должна быть видна в контейнере Spring с использованием аннотации @ComponentScan или конфигурации xml.

Статья Spring bean scopes с сайта baeldung

действительно используйте BeanFactory для не веб-приложений, потому что он поддерживает только объекты bean-объектов Singleton и Prototype.

Хотя контейнер ApplicationContext поддерживает все области действия bean-компонентов, вы должны использовать его для веб-приложений.

В итоге:

ApplicationContext включает в себя все функции BeanFactory. Обычно рекомендуется использовать первое.

Есть несколько ограниченных ситуаций, например, в мобильном приложении, когда потребление памяти может быть критическим.

В этих сценариях может быть оправдано использование более легкого BeanFactory. Однако в большинстве корпоративных приложений вы захотите использовать ApplicationContext.

Для получения дополнительной информации см. Мое сообщение в блоге:

Разница между BeanFactory и ApplicationContext в Spring - блог java spring от основ

Мне нужно объяснить BeanFactory и ApplicationContext.

BeanFactory: BeanFactory - это корневой интерфейс для доступа к контейнеру SpringBean. Существует базовое клиентское представление контейнера bean-компонентов. Этот интерфейс реализуется классом объектов, который содержит количество определений bean-компонентов, и каждое из них уникально идентифицируется строковым именем
. В зависимости от определения Бина фабрика вернет экземпляр, который может быть экземпляром содержащегося объекта или единственным совместно используемым экземпляром. Тип возвращаемого экземпляра зависит от заводской конфигурации компонента. Обычно фабрика Bean загружает все определения всех beans, которые хранятся в источнике конфигурации, например XML ... и т. д.

BeanFactory - это простейший контейнер, обеспечивающий базовую поддержку внедрения зависимостей.

Контекст приложения Контекст приложения - это центральный интерфейс с приложением Spring, который предоставляет информацию о конфигурации приложению. Он реализует интерфейс Bean Factory.

Контекст приложения - это расширенный контейнер, который добавляет расширенный уровень специфической для предприятия функциональности, такой как возможность разрешать текстовое сообщение из файла свойств ... и т. д.

ApplicationContext обеспечивает:

Методы фабрики компонентов для доступа к компонентам приложения. Унаследовано от ListableBeanFactory. Возможность загружать файловые ресурсы обычным образом. Унаследовано от интерфейса ResourceLoader. Возможность публиковать события для зарегистрированных слушателей. Унаследовано от интерфейса ApplicationEventPublisher. Возможность разрешать сообщения, поддерживающие интернационализацию. Унаследовано от интерфейса MessageSource. Наследование от родительского контекста. Определения в контексте потомка всегда будут иметь приоритет. Это означает, например, что единственный родительский контекст может использоваться всем веб-приложением, в то время как каждый сервлет имеет свой собственный дочерний контекст, который не зависит от контекста любого другого сервлета. В дополнение к стандартным возможностям жизненного цикла BeanFactory, реализации ApplicationContext обнаруживают и вызывают компоненты ApplicationContextAware, а также компоненты ResourceLoaderAware, ApplicationEventPublisherAware и MessageSourceAware.