BeanFactory vs ApplicationContext

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

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

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

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

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

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

Ответ 1

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

Bean Factory

  • Bean instantiation/wiring

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

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

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

Ответ 2

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

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

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

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

То, что я закончил, - это расширение ClassPaспасибоmlApplicationContext для ленивой загрузки компонентов для использования в тестах следующим образом:

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

}

Ответ 3

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                            |
+---------------------------------------+-----------------+--------------------------------+

enter image description here

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

пример:

  ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeansConfiguration.class);
  • ApplicationContext - это контейнер, инициализированный ContextLoaderListener или ContextLoaderServlet определенным в web.xml и ContextLoaderPlugin определенным в ContextLoaderPlugin struts-config.xml.

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

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

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

РАЗНИЦА

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

  • BeanFactory не поддерживает интернационализацию, но ApplicationContext поддерживает его.

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

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

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

  • BeanFactory по умолчанию поддерживает Lazy и ApplicationContext по умолчанию поддерживает Aggresive.

Ответ 11

Отличие между BeanFactory и ApplicationContext:

  • BeanFactory использует ленивую инициализацию , но ApplicationContext использует надежную инициализацию. В случае BeanFactory создается bean, когда вы вызываете метод getBeans(), но bean создается заранее в случае ApplicationContext при создании объекта ApplicationContext.
  • BeanFactory явно предоставляет объект ресурса с использованием синтаксиса , но ApplicationContext создает и управляет объектами ресурсов самостоятельно.
  • BeanFactory не поддерживает интернационализацию , но ApplicationContext поддерживает интернационализацию.
  • В случае, когда приложение 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");

Ответ 12

Матрица функций Bean Factory vs Контекст приложения получен из spring docs

введите описание изображения здесь

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

Ответ 13

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

  • с помощью BeatFactory
  • с помощью ApplicationContext

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

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

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

BeanFactory

  • Не поддерживает Injection зависимую от аннотации.

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

  • По умолчанию его поддержка Lazy loading

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

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

ApplicationContext

  • Поддержка, основанная на аннотациях, [email protected], @PreDestroy

  • Поддержка I18N

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

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

например:
ApplicationContext context = new ClasspaспасибоmlApplicationContext ( "applicationContext.xml" );

Ответ 14

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

б.

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

или

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

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

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

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

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

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

г. Контейнер Beanfactory поддерживает только две области (одиночный и прототип) beans. Но ApplicationContext Container поддерживает все области beans.

Ответ 15

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

Ответ 16

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

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

Ответ 17

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

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

Ответ 18

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

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

  • BeanFactory: (Lazy container, потому что он создает объекты для beans только при явном вызове пользователя/основного класса)

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

    ApplicationContext context = new ClassPathXmlApplicationContext("com/ioc/constructorDI/resources/spring.xml");
    
  • Технически рекомендуется использовать ApplicationContext, потому что в приложениях реального времени объекты bean будут созданы, когда приложение запускается на самом сервере. Это уменьшает время отклика для пользовательского запроса, поскольку объекты уже доступны для ответа.

Ответ 19

Основные ссылки Spring попытаются провести четкое сравнение BeanFactory с ApplicationContext. Я попытаюсь упомянуть их в этом разделе, чтобы ответить на ваш вопрос. Основной контейнер IoC в Spring называется bean factory. Любой bean factory обеспечивает согласованность и работоспособность конфигурации и проводки между объектами, использующими инъекцию зависимостей.

Все фабрики bean реализуют org.springframework.beans.factory. BeanFactory, с экземплярами, доступными через этот интерфейс, если им необходимо управлять программным способом. Существуют суб-интерфейсы BeanFactory, которые предоставляют дополнительную функциональность.

Spring также поддерживает несколько более продвинутый bean factory, называемый контекстом приложения. Важно подчеркнуть, что контекст приложения представляет собой bean factory, а важный интерфейс org.springframework.context.ApplicationContext является подклассом BeanFactory.

Вообще говоря, все, что может сделать bean factory, может также иметь контекст приложения. На поверхности ApplicationContext имеет то же самое, что и BeanFactory. Оба загружают определения bean, провод beans вместе и выдают beans по запросу. Почему различие? Это сводится в основном к увеличению функциональности и стилю использования:

  • Общий стиль использования, ориентированный на каркас: некоторые операции с контейнером или beans в контейнере, которые должны обрабатываться программным способом с помощью bean factory, могут обрабатываться декларативно в контекст приложения. Это включает автоматическое распознавание и использование специальных постпроцессоров bean и постпроцессоров bean factory, которые будут описаны в ближайшее время. Кроме того, существует ряд средств Spring Framework для автоматической загрузки контекстов приложений, например, на уровне веб-MVC, так что bean фабрики будут в основном созданы с помощью кода пользователя, но контексты приложений будут в основном использоваться декларативно, созданный с помощью кода структуры.

  • Поддержка MessageSource: контекст приложения реализует MessageSource, интерфейс, используемый для получения локализованных сообщений, при этом фактическая реализация может быть подключаема.

  • Поддержка приложений и фреймворков: контекст способен запускать фреймворки или приложения для зарегистрированных слушателей.

  • Поддержка ResourceLoader: Spring Интерфейс ресурсов - это гибкая общая абстракция для обработки ресурсов низкого уровня. Самым контекстом приложения является ResourceLoader, поэтому он предоставляет приложение с доступом к экземплярам ресурса, специфичным для развертывания.

Вам может быть интересно, когда наиболее целесообразно создавать и использовать bean factory в сравнении с контекстом приложения. A bean factory отлично подходит для простых приложений, но для того, чтобы воспользоваться всеми возможностями структуры Spring, вы можете перейти к более продвинутому контейнеру Spring, контекст приложения.

Практически во всех случаях вам лучше использовать контекст приложения, потому что вы получите больше возможностей без каких-либо реальных затрат. Основное исключение - это что-то вроде апплета, мобильного устройства... где каждый последний байт используемой (или перенесенной) памяти имеет значение, а bean factory сохранит некоторую память, потому что вы можете использовать Spring библиотечный пакет, который вносит только функциональность bean factory, не привнося в контекст контекста приложения.

Ответ 20

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

@Configuration
public class MyFactory {

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

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

Весенняя фасоль - предмет с сайта baeldung

Ответ 21

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

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

Ответ 22

В итоге:

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

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

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

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

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