Я довольно новичок в Spring Framework, я играл с ним и собирал несколько примеров приложений для оценки Spring MVC для использования в будущем проекте компании. Пока что мне действительно нравится то, что я вижу в Spring MVC, оно кажется очень простым в использовании и побуждает вас писать классы, которые очень удобны для модульных тестов.
В качестве упражнения я пишу основной метод для одного из моих примеров / тестовых проектов. Одна вещь, о которой мне неясно, это точные различия между BeanFactory
и ApplicationContext
- что уместно использовать в каких условиях?
Я понимаю, что это ApplicationContext
расширяется BeanFactory
, но если я просто пишу простой метод main, мне нужна дополнительная функциональность, которая ApplicationContext
обеспечивает? И какой именно дополнительный функционал ApplicationContext
предоставляет?
Помимо ответа «что мне следует использовать в методе main ()», существуют ли какие-либо стандарты или рекомендации относительно того, какую реализацию мне следует использовать в таком сценарии? Должен ли мой метод main () быть написан так, чтобы он зависел от конфигурации компонента / приложения в формате XML - это безопасное предположение, или я блокирую пользователя на что-то конкретное?
И изменится ли этот ответ в веб-среде - если кому-то из моих классов нужно было знать о Spring, они, скорее всего, понадобятся ApplicationContext
?
Спасибо за любую помощь. Я знаю, что на многие из этих вопросов, вероятно, даны ответы в справочном руководстве, но мне трудно найти четкую разбивку этих двух интерфейсов и плюсов / минусов каждого без чтения руководства с помощью расчески с мелкими зубьями.
BeanFactory
мы можем передавать параметры конструктора динамически, ноApplicationContext
мы не можем этого сделать.FileSystemXmlApplicationContext
Бобы загружаются по полному пути.ClassPathXmlApplicationContext
Бобы, загруженные через CLASSPATHXMLWebApplicationContext
иAnnotationConfigWebApplicationContext
бины, загруженные через контекст веб-приложения.AnnotationConfigApplicationContext
Загрузка бобов Spring из конфигурации на основе аннотаций.пример:
ApplicationContext
является контейнером, инициализированнымContextLoaderListener
илиContextLoaderServlet
определенным вweb.xml
иContextLoaderPlugin
определенным вstruts-config.xml
.Примечание :
XmlBeanFactory
это не рекомендуется с весны 3.1 в пользуDefaultListableBeanFactory
иXmlBeanDefinitionReader
.источник
Для меня главное отличие выбрать
BeanFactory
более ,ApplicationContext
кажется, чтоApplicationContext
будет предварительно Instantiate все бобы. С тех пружинных документов :Учитывая это, я изначально выбрал
BeanFactory
использование в тестах интеграции / производительности, так как не хотел загружать все приложение для тестирования изолированных bean-компонентов. Однако - и кто-то поправит меня, если я ошибаюсь -BeanFactory
не поддерживаетclasspath
конфигурацию XML. Таким образом ,BeanFactory
иApplicationContext
каждый из них предоставляет важную особенность , которую я хотел, но ни один не сделал обоих.Насколько я могу судить, примечание в документации о переопределении поведения экземпляров по умолчанию имеет место в конфигурации, и это для каждого компонента, поэтому я не могу просто установить атрибут "lazy-init" в файле XML, или я попробую поддерживать его версию для тестирования и одну для развертывания.
В итоге я продолжил
ClassPathXmlApplicationContext
лениво загружать бины для использования в таких тестах:источник
BeanFactory doesn't support classpath XML configuration.
Я думаю, что это так: stackoverflow.com/questions/5231371/…Чтобы добавить то, на что ответил Мигель Пинг, вот еще один раздел документации, который также отвечает на это:
(опубликовать это для любых будущих новичков Spring, которые могут прочитать этот вопрос)
источник
ApplicationContext
является более предпочтительным способом, чемBeanFactory
В новых версиях Spring
BeanFactory
заменен наApplicationContext
. Но все ещеBeanFactory
существует для обратной совместимостиApplicationContext extends BeanFactory
и имеет следующие преимуществаисточник
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 и выбирать, какой интерфейс реализовать.
источник
ApplicationContext
включает в себя все функциональные возможностиBeanFactory
, обычно рекомендуется использовать его в предпочтенииBeanFactory
, за исключением нескольких ограниченных ситуаций, таких как в случаеApplet
, когда потребление памяти может быть критическим, и несколько дополнительных килобайт могут Сделать разницу. Тем не менее, для большинства «типичных» корпоративных приложений и систем именно то,ApplicationContext
что вы захотите использовать.Разница между BeanFactory и ApplicationContext заключается в следующем:
Использование BeanFactory:
Использование ApplicationContext:
источник
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, для которого существует несколько реализаций.
РАЗНИЦА
BeanFactory создает экземпляр компонента, когда вы вызываете метод getBean (), в то время как ApplicationContext создает экземпляр компонента Singleton при запуске контейнера. Он не ожидает вызова getBean ().
BeanFactory не обеспечивает поддержку интернационализации, но ApplicationContext обеспечивает ее поддержку.
Другое отличие BeanFactory от ApplicationContext заключается в возможности публиковать события в bean-компонентах, которые зарегистрированы как слушатели.
Одной из популярных реализаций интерфейса BeanFactory является XMLBeanFactory, а одной из популярных реализаций интерфейса ApplicationContext является ClassPathXmlApplicationContext .
Если вы используете автоматическое подключение и используете BeanFactory, вам нужно зарегистрировать AutoWiredBeanPostProcessor с помощью API, который можно настроить в XML, если вы используете ApplicationContext . Таким образом, BeanFactory подходит для тестирования и непроизводственного использования, но ApplicationContext является более многофункциональной реализацией контейнера и должен быть предпочтительнее BeanFactory.
BeanFactory по умолчанию его поддержки отложенной загрузки и ApplicationContext по умолчанию поддержки агрессивны нагрузки.
источник
Функциональная матрица Bean Factory и контекст приложения получены из весенних документов
Снимок экрана с функциями BeanFacotry и ApplicationContext
источник
а. Одно из различий между фабрикой компонентов и контекстом приложения заключается в том, что прежний экземпляр компонента создается только при вызове метода getBean (), а ApplicationContext создает экземпляр компонента Singleton при запуске контейнера. Он не ожидает вызова getBean.
б.
или
Вы можете использовать один или несколько 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 двумя способами.
оба являются интерфейсами,
используя классы реализации, мы можем создать объект для контейнера Spring
приходя к различиям
BeanFactory:
Не поддерживает внедрение зависимостей на основе аннотаций.
Не поддерживает I18N.
По умолчанию его поддержка Ленивая загрузка.
он не позволяет настраивать несколько файлов конфигурации.
например: BeanFactory context = new XmlBeanFactory (new Resource ("applicationContext.xml"));
ApplicationContext
Поддержка аннотаций на основе зависимости Injection.-@Autowired, @PreDestroy
Поддержка I18N
По умолчанию поддерживается агрессивная загрузка.
Это позволяет настроить несколько файлов конфигурации.
например:
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) заключается в следующем.
BeanFactory будет создавать объекты для bean-компонентов (то есть для классов POJO), упомянутых в файле spring.xml (
<bean></bean>
), только когда вы вызываете метод .getBean (), а ApplicationContext создает объекты для всех bean-компонентов (<bean></bean>
если его область действия не явно упоминается как «Prototype»), настроенный в spring.xml при загрузке самого файла spring.xml.BeanFactory: (Ленивый контейнер, потому что он создает объекты для bean-компонентов только при явном вызове из пользовательского / основного класса)
ApplicationContext: (нетерпеливый контейнер из-за создания объектов всех одноэлементных компонентов при загрузке самого файла spring.xml)
Технически рекомендуется использовать ApplicationContext, поскольку в приложениях реального времени объекты bean-объектов будут создаваться во время запуска приложения на самом сервере. Это сокращает время ответа на запрос пользователя, поскольку объекты уже доступны для ответа.
источник
Я думаю, что стоит упомянуть, что начиная с весны 3, если вы хотите создать фабрику, вы также можете использовать
@configuration
аннотацию в сочетании с@scope
Ваша фабрика должна быть видна контейнеру 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,
источник