BeanFactory против ApplicationContext - PullRequest
Новая
       127

BeanFactory против ApplicationContext

217 голосов
/ 28 октября 2008

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

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

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

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

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

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

Ответы [ 19 ]

4 голосов
/ 30 июня 2015

Матрица возможностей Бобовой Фабрики и Контекст Приложения Получено из документов Spring

enter image description here

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

3 голосов
/ 06 января 2017

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

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

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

3 голосов
/ 18 января 2016

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

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

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

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

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

BeanFactory

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

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

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

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

ex: BeanFactory context = new XmlBeanFactory (new Resource ("applicationContext.xml"));

ApplicationContext

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

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

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

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

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

1 голос
/ 27 апреля 2013

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

1 голос
/ 26 февраля 2016

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

1 голос
/ 26 февраля 2015

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

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

0 голосов
/ 07 июля 2018

В итоге:

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

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

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

Подробнее см. В моем блоге:

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

0 голосов
/ 22 апреля 2018

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

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

0 голосов
/ 23 января 2018

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

@Configuration
public class MyFactory {

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

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

Статья с бобами из ячменя

Страница:
...