BeanFactory v / s ApplicationContext, объяснение с помощью примера кода [duplicate]

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

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

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

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

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

DIFFERENCE

1. BeanFactory создает экземпляр компонента, когда вы вызываете метод getBean (), в то время как ApplicationContext создает экземпляр Singleton, когда контейнер запущен, 't ждать вызова getBean ().
2. BeanFactory не обеспечивает поддержку интернационализации, но ApplicationContext поддерживает его.
3. Еще одно отличие BeanFactory от ApplicationContext - возможность публикации event to beans, зарегистрированные в качестве слушателя.
4. Одной из популярных реализаций интерфейса BeanFactory является XMLBeanFactory, а одной из популярных реализаций интерфейса ApplicationContext является ClassPathXmlApplicationContext.
5. Если y ou используют автоматическую проводку и используют BeanFactory, чем вам необходимо зарегистрировать AutoWiredBeanPostProcessor, используя API, который вы можете настроить в XML, если используете ApplicationContext. В итоге BeanFactory подходит для тестирования и не производственного использования, но ApplicationContext - это более многофункциональная реализация контейнера и должна быть одобрена BeanFactory
6. . BeanFactory по умолчанию поддерживает Lazy loading и ApplicationContext по умолчанию поддерживает загрузку Aggresive.

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

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

1. BeanFactory использует ленивый подход к инициализации, тогда как ApplicationContext использует надежный подход к инициализации. т.е. BeanFactory создает одноэлементный компонент только тогда, когда он запрашивается у него, но ApplicationContext создает все одноэлементные компоненты во время его собственной инициализации.
2. ApplicationContext создает и управляет объектами ресурсов сам по себе, тогда как BeanFactory был явно предоставлен объект ресурса с использованием синтаксиса:

   ClassPathResource resource = new ClassPathResource("beans.xml");
   
   XmlBeanFactory factory = new XmlBeanFactory(resource); // Here resource object is provided explicitly
   

3. ApplicationContext поддерживает интернационализацию, но BeanFactory этого не делает.
4. зависимость от зависимостей Injection не поддерживается BeanFactory, тогда как ApplicationContext поддерживает использование аннотации @PreDestroy, @ Autowired.

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

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

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

Кроме того, помните, что вы можете использовать несколько конфигурационных файлов Spring, и вы можете либо создать ApplicationContext, указав все файлы в конструкторе (или указав их в контексте-param для ContextLoaderListener), либо вы можете просто загрузите основной файл конфигурации с инструкциями импорта. Вы можете импортировать файл конфигурации Spring в другой файл конфигурации Spring, используя & lt; import resource = "otherfile.xml" / & gt; что очень полезно при программном создании ApplicationContext в основном методе и загрузке только одного конфигурационного файла Spring.

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

а. Одна разница между компонентом фабрики и контекстом приложения заключается в том, что бывший только экземпляр компонента, когда вы вызываете метод 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 является базовым контейнером, он может создавать объекты и вводить зависимости. Но мы не можем прикреплять другие сервисы, такие как безопасность, транзакция, обмен сообщениями и т. Д., Чтобы предоставить все сервисы, которые мы должны использовать ApplicationContext Container.

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

e. Контейнер BeanFactory не поддерживает функцию AutoScanning (поддержка Injection на основе зависимостей на основе аннотации), но поддерживает ApplicationContext Container.

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

g. Контейнер Beanfactory поддерживает только две области (singleton & amp; prototype) из фасоли. Но ApplicationContext Container поддерживает всю область beans.

Для меня основное отличие, чтобы выбрать BeanFactory над ApplicationContext, похоже, что ApplicationContext будет предварительно создавать все бобы. Из Spring docs:

Spring устанавливает свойства и разрешает зависимости как можно позже, когда компонент фактически создан. Это означает, что контейнер Spring, который правильно загрузился, может позже генерировать исключение, когда вы запрашиваете объект, если есть проблема с созданием этого объекта или одной из его зависимостей. Например, бит генерирует исключение в результате отсутствия или недопустимого свойства. Эта потенциально задержка видимости некоторых проблем с конфигурацией заключается в том, что реализации ApplicationContext по умолчанию представляют собой предварительные экземпляры одноэлементных бэнов. За счет некоторого времени и памяти для создания этих компонентов до того, как они действительно понадобятся, вы обнаружите проблемы с конфигурацией при создании ApplicationContext, а не позже. Вы по-прежнему можете переопределить это поведение по умолчанию, так что однопользовательские beans будут lazy-initialize, а не быть предварительно созданными.

Учитывая это, я изначально выбрал BeanFactory для использования в тестах интеграции / производительности так как я не хотел загружать все приложение для тестирования изолированных бобах. Однако - и кто-то меня исправит, если я ошибаюсь - BeanFactory не поддерживает конфигурацию XML classpath. Таким образом, BeanFactory и ApplicationContext каждый из них предоставляет важную функцию, которую я хотел, но также и то и другое.

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

Что я в конечном итоге делалось расширение ClassPathXmlApplicationContext до лениво загружаемых бобов для использования в тестах следующим образом:

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

}

• BeanFactory: не поддерживает зависимость от зависимостей на основе аннотации.
• ApplicationContext: поддержка зависимостей на основе аннотации. - @ Autowired, @PreDestroy
• BeanFactory: не поддерживает
• ApplicationContext: контексты приложения могут публиковать события в beans, зарегистрированные в качестве слушателей
• BeanFactory: не (j18N)
• ApplicationContext: сообщения о поддержке интернационализации (I18N).
• BeanFactory: не поддерживается.
• ApplicationContext: Поддержка многих корпоративных сервисов, таких как JNDI-доступ, интеграция EJB, удаленный доступ.
• BeanFactory: по умолчанию его поддержка Lazy loading
• ApplicationContext: по умолчанию поддерживает загрузку Aggresive.

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

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

   /*
    * 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: (контейнер Eager из-за создания объектов всех одноэлементных компонентов при загрузке самого файла spring.xml)

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

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

Матрица функций фабрики Bean vs Application Context получена из весенних документов

Снимок экрана с функциями BeanFacotry и ApplicationContext

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

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

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

Spring предоставляет два вида контейнера IOC, один - XMLBeanFactory, а другой - 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 Бобы, загруженные через компоненты CLASSPATH
• XMLWebApplicationContext и AnnotationConfigWebApplicationContext, загруженные через контекст веб-приложения.
• AnnotationConfigApplicationContext Загрузка Spring beans из конфигурации на основе аннотаций.

Пример

:

  ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeansConfiguration.class);

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

Разница между 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)beanFactory.getBean("triangle");

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

@Configuration
public class MyFactory {

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

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

от места baeldung

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

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

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

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

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

1. с использованием BeatFactory
2. с использованием ApplicationContext

оба являются интерфейсами

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

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

BeanFactory

1. Не поддерживает аннотацию основанная на зависимостях Injection.
2. Не поддерживает I18N
3. По умолчанию его поддержка Lazy loading
4. не позволяет настроить несколько файлов конфигурации.

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

ApplicationContext

1. Поддержка зависимостей на основе аннотаций Инъекция .- @ Autowired, @PreDestroy
2. Поддержка I18N
3. its По умолчанию поддерживается загрузка Aggresive.
4. позволяет настраивать несколько файлов конфигурации.

ex: ApplicationContext context = new ClasspathXmlApplicationContext ("applicationContext.xml");

Разница между BeanFactory и ApplicationContext:

Интерфейсы org.springframework.beans.factory.BeanFactory и org.springframework.context.ApplicationContext действуют как контейнер IoC. Интерфейс ApplicationContext построен поверх интерфейса BeanFactory. Он добавляет некоторые дополнительные функции, чем BeanFactory, такие как простая интеграция с AOP Spring, обработка ресурсов сообщений (для I18N), распространение событий, контекст специфического уровня приложения (например, WebApplicationContext) для веб-приложения. Поэтому лучше использовать ApplicationContext, чем BeanFactory.

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

ApplicationContext: он загружает весенние бобы, настроенные в файле конфигурации пружины, и управляет жизненным циклом весеннего боба, а КОГДА КОНТЕЙНЕР STARTS. Он не будет ждать, пока не будет вызван getBean ("springbeanref").

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

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

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

Вкратце:

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

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

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

Подробнее о:

Разница между BeanFactory и ApplicationContext весной - java spring blog из основ