BeanFactory против ApplicationContext

Я довольно новичок в Spring Framework, я играл с ним и собирал несколько примеров приложений для оценки Spring MVC для использования в будущем проекте компании. Пока что мне действительно нравится то, что я вижу в Spring MVC, оно кажется очень простым в использовании и побуждает вас писать классы, которые очень удобны для модульных тестов.

В качестве упражнения я пишу основной метод для одного из моих примеров / тестовых проектов. Одна вещь, о которой мне неясно, это точные различия между BeanFactoryи ApplicationContext- что уместно использовать в каких условиях?

Я понимаю, что это ApplicationContextрасширяется BeanFactory, но если я просто пишу простой метод main, мне нужна дополнительная функциональность, которая ApplicationContextобеспечивает? И какой именно дополнительный функционал ApplicationContextпредоставляет?

Помимо ответа «что мне следует использовать в методе main ()», существуют ли какие-либо стандарты или рекомендации относительно того, какую реализацию мне следует использовать в таком сценарии? Должен ли мой метод main () быть написан так, чтобы он зависел от конфигурации компонента / приложения в формате XML - это безопасное предположение, или я блокирую пользователя на что-то конкретное?

И изменится ли этот ответ в веб-среде - если кому-то из моих классов нужно было знать о Spring, они, скорее всего, понадобятся ApplicationContext ?

Спасибо за любую помощь. Я знаю, что на многие из этих вопросов, вероятно, даны ответы в справочном руководстве, но мне трудно найти четкую разбивку этих двух интерфейсов и плюсов / минусов каждого без чтения руководства с помощью расчески с мелкими зубьями.

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

Бобовая Фабрика

• Реализация бина / проводка

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

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

Поэтому, если вам нужны какие-либо из пунктов, представленных на стороне контекста приложения, вы должны использовать 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 из конфигурации на основе аннотаций.

пример:

ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeansConfiguration.class);

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

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

Для меня главное отличие выбрать BeanFactoryболее , ApplicationContextкажется, что ApplicationContextбудет предварительно Instantiate все бобы. С тех пружинных документов :

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

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

Насколько я могу судить, примечание в документации о переопределении поведения экземпляров по умолчанию имеет место в конфигурации, и это для каждого компонента, поэтому я не могу просто установить атрибут "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);
        }
    }

}

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

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

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

1. ApplicationContext является более предпочтительным способом, чем BeanFactory

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

РАЗНИЦА

1. BeanFactory создает экземпляр компонента, когда вы вызываете метод getBean (), в то время как ApplicationContext создает экземпляр компонента 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 по умолчанию поддержки агрессивны нагрузки.

Функциональная матрица Bean Factory и контекст приложения получены из весенних документов

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

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

б.

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

или

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

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

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

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

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

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

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

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

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

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

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

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

BeanFactory:

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

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

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

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

например: BeanFactory context = new XmlBeanFactory (new Resource ("applicationContext.xml"));

ApplicationContext

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

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

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

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

например:
ApplicationContext context = new ClasspathXmlApplicationContext ("applicationContext.xml");

См. Этот документ из 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, достаточное количество поддержки, такой как транзакции и AOP, не вступят в силу, по крайней мере, без каких-либо дополнительных шагов с вашей стороны. Эта ситуация может сбить с толку, потому что на самом деле все в порядке с конфигурацией.

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

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

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

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

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

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

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

@Configuration
public class MyFactory {

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

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

Статья о бобах из весеннего боба с сайта baeldung

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

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

В итоге:

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

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

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

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

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

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

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

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

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

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

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

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