BeanFactory по сравнению с ApplicationContext

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

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

, Если Ваша разработка веб-приложения, смело можно сказать, необходимо будет использовать XmlWebApplicationContext.

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

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

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

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

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

Для добавления на то, на что ответил Miguel Ping вот другой раздел из документации , который отвечает на это также:

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

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

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

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

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

На мой взгляд, основная разница в выборе BeanFactory вместо ApplicationContext заключается в том, что ApplicationContext предварительно создаст экземпляры всех компонентов. Из Spring docs :

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

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

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

В итоге я расширил 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);
        }
    }

}