BeanFactory vs ApplicationContext

Question

저는 Spring Framework에 익숙하지 않습니다. 나는 다가오는 회사 프로젝트에서 사용하기 위해 Spring MVC를 평가하기 위해 몇 가지 샘플 앱을 모으고 있습니다. 지금까지 나는 Spring MVC에서 내가 보는 것을 정말로 좋아하고, 사용하기 쉬운 것처럼 보이며, 단위 테스트 친화적 인 수업을 작성하도록 권장합니다.

운동과 마찬가지로 샘플/테스트 프로젝트 중 하나의 주요 방법을 작성하고 있습니다. 내가 불분명 한 한 가지는 정확한 차이점입니다. BeanFactory 그리고 ApplicationContext - 어느 조건에서 사용하기에 적합한 것은 무엇입니까?

나는 이해 ApplicationContext 확장 BeanFactory,하지만 간단한 주요 방법을 작성하는 경우 추가 기능이 필요합니까? ApplicationContext 제공합니까? 그리고 정확히 어떤 종류의 추가 기능이하는지 정확히 일치합니다 ApplicationContext 제공하다?

"Main () 메소드에서 사용해야하는 것"에 대답하는 것 외에도 그러한 시나리오에서 어떤 구현을 사용해야하는 한 표준이나 지침이 있습니까? Main () 메소드가 Bean/Application 구성에 XML 형식으로 의존하도록 작성해야합니다. 안전한 가정입니까, 아니면 사용자를 구체적인 것으로 고정하고 있습니까?

그리고이 답변이 웹 환경에서 변경됩니까? ApplicationContext?

도움을 주셔서 감사합니다. 나는이 질문들 중 많은 부분이 참조 매뉴얼에서 답변 될 수 있지만,이 두 인터페이스와 미세한 빗으로 매뉴얼을 읽지 않고 각각의 장단점을 명확하게 파괴하는 데 어려움을 겪고 있습니다.

Answer 1

스프링 문서는 이것에 훌륭합니다. 3.8.1. BeanFactory 또는 ApplicationContext?. 비교가있는 테이블이 있습니다. 스 니펫을 게시하겠습니다.

콩 공장

• 콩 인스턴스화/배선

응용 프로그램 컨텍스트

• 콩 인스턴스화/배선
• 자동 BeanPostProcessor 등록
• 자동 BeanFactoryPostProcessor 등록
• 편리한 메시지 소스 액세스 (I18N의 경우)
• ApplicationEvent 출판

따라서 응용 프로그램 컨텍스트 측면에 제시된 포인트가 필요한 경우 ApplicationContext를 사용해야합니다.

Answer 2

나에게 선택해야 할 주요 차이점 BeanFactory ~ 위에 ApplicationContext 그게 보인다 ApplicationContext 모든 콩을 사전에 전달합니다. 에서 그만큼 봄 문서:

스프링은 콩이 실제로 생성 될 때 가능한 한 늦게 속성을 설정하고 의존성을 해결합니다. 이는 올바르게로드 된 스프링 컨테이너가 해당 객체 또는 해당 종속성 중 하나를 만드는 데 문제가있는 경우 객체를 요청할 때 예외를 나중에 생성 할 수 있음을 의미합니다. 예를 들어, 콩은 누락되거나 유효하지 않은 속성의 결과로 예외를 던집니다. 이 일부 구성 문제의 가시성이 지연되는이 가시성은 기본적으로 전염병 전 싱글 톤 Beans에 의해 ApplicationContext 구현이 필요한 이유입니다. 실제로 필요한 콩을 만들기 위해 선불 시간과 메모리가 실제로 필요하기 전에 이러한 콩을 생성하는 비용으로, ApplicationContext가 생성 될 때 나중에 아닌 구성 문제를 발견합니다. 싱글 톤 콩이 사전에 감염되지 않고 게으른 초기화를 할 수 있도록이 기본 동작을 여전히 무시할 수 있습니다.

이것을 감안할 때, 나는 처음에 선택했다 BeanFactory 고립 된 콩을 테스트하기 위해 전체 애플리케이션을로드하고 싶지 않았기 때문에 통합/성능 테스트에 사용합니다. 그러나 -그리고 내가 틀렸다면 누군가가 나를 교정합니다. BeanFactory 지원하지 않습니다 classpath XML 구성. 그래서 BeanFactory 그리고 ApplicationContext 각각은 내가 원했던 중요한 기능을 제공하지만 둘 다도 마찬가지입니다.

내가 알 수 있듯이, 기본 인스턴스화 동작을 재정의하는 것에 대한 문서의 메모는 구성에서 발생하며 빔당이므로 XML 파일에 "Lazy-Init"속성을 설정할 수는 없거나 XML 파일에 설정할 수 없습니다. 테스트를 위해 IT 버전을 유지 관리하고 배포를위한 버전을 유지했습니다.

내가 한 일은 확장하는 것이 었습니다 ClassPathXmlApplicationContext SO와 같은 테스트에 사용하기 위해 콩을 게으르게 적재합니다.

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

}

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

• FileSystemXmlApplicationContext 전체 경로를 통해 콩.
• ClassPathXmlApplicationContext 클래스 경로를 통해 콩
• XMLWebApplicationContext 그리고 AnnotationConfigWebApplicationContext 웹 응용 프로그램 컨텍스트를 통해로드 된 콩.
• AnnotationConfigApplicationContext 주석 기반 구성에서 스프링 콩을로드합니다.

예시:

  ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeansConfiguration.class);

• ApplicationContext 컨테이너는 a ContextLoaderListener 또는 ContextLoaderServlet a web.xml 그리고 ContextLoaderPlugin 정의되었습니다 struts-config.xml.

메모: XmlBeanFactory ~이다 감가 상각 된 봄 3.1 기준으로 DefaultListableBeanFactory 그리고 XmlBeanDefinitionReader.

Answer 4

Miguel Ping이 대답 한 것에 추가하기 위해 여기에 문서의 다른 섹션 이에 대한 대답도 다음과 같습니다.

짧은 버전 : 그렇게하지 않은 이유가 없다면 ApplicationContext를 사용하십시오. 위의 추천의 '그러나 왜'에 대해 약간 더 깊이를 찾고있는 사람들에게는 계속 읽으십시오.

(이 질문을 읽을 수있는 미래의 봄 초보자에게 이것을 게시)

Answer 5

1. ApplicationContext 보다 선호하는 방법입니다 BeanFactory

2. 새로운 스프링 버전에서 BeanFactory 대체됩니다 ApplicationContext. 그러나 여전히 BeanFactory 후진 호환성을 위해 존재합니다

3. ApplicationContext extends BeanFactory 다음과 같은 이점이 있습니다
   • 문자 메시지의 국제화를 지원합니다
   • 등록 된 청취자에게 이벤트 출판물을 지원합니다
   • URL 및 파일과 같은 리소스에 대한 액세스

Answer 6

다른 사람이 이미 말한 것처럼 모바일 환경에 있지 않는 한 항상 ApplicationContext를 사용하는 것이 낫다고 생각합니다. ApplicationContext는 더 많은 기능을 가지고 있으며 QuessionAntationBeanPostProcessor, AutowiredAnnotationBeanPostProcessor 및 CommonAnnotationBeanPostProcessor와 같은 후 처리기를 사용하려고합니다. 이는 스프링 구성 파일을 단순화하는 데 도움이되며 @Required, @PostConstruct 등과 같은 주석을 사용할 수 있습니다. .

ApplicationContext가 제공하는 모든 재료를 사용하지 않더라도 어쨌든 사용하는 것이 좋습니다. 나중에 메시지 나 Post Processor 또는 다른 스키마와 같은 일부 리소스를 사용하여 트랜잭션 조언 등을 추가하기로 결정한 경우 나중에 사용하는 것이 좋습니다. 이미 ApplicationContext가 있으며 코드를 변경할 필요가 없습니다.

독립형 앱을 작성하는 경우 ClassPathXmlApplicationContext를 사용하여 Main Method에 ApplicationContext를로드하고 기본 Bean을 가져 와서 run (또는 모든 메소드)을 호출하여 앱을 시작하십시오. 웹 앱을 작성하는 경우 web.xml에서 ContextLoaderListener를 사용하여 ApplicationContext를 생성하고 JSP, JSF, Struts, Tapestry 등을 사용하는지 여부에 관계없이 ServletContext에서 나중에 얻을 수 있습니다. .

또한 여러 스프링 구성 파일을 사용할 수 있으며 생성자에 모든 파일을 나열하거나 ContextLoaderListener의 Context-Param에 나열하여 ApplicationContext를 만들 수 있습니다. 수입 명세서. 사용하여 스프링 구성 파일을 다른 스프링 구성 파일로 가져올 수 있습니다.u003Cimport resource="otherfile.xml" /> 이는 기본 메소드에서 ApplicationContext를 프로그래밍 방식으로 작성하고 하나의 스프링 구성 파일 만로드 할 때 매우 유용합니다.

Answer 7

ApplicationContext :스프링 구성 파일로 구성된 스프링 빈을로드하고 컨테이너가 시작될 때 스프링 콩의 수명주기를 관리합니다. getbean ( "SpringbeanRef") 호출됩니다.

멍청한스프링 구성 파일로 구성된 스프링 콩을로드하고, 우리가 호출 할 때 스프링 콩의 수명주기를 관리합니다. getbean ( "SpringbeanRef"). 그래서 우리가 전화 할 때 getbean ( "SpringbeanRef") 봄 콩 수명주기가 시작될 때 시작됩니다.

Answer 8

대부분의 경우 모바일 애플리케이션과 같이 리소스를 저장하지 않으면 ApplicationContext가 선호됩니다.

XML 형식에 따라 확실하지 않지만 ApplicationContext의 가장 일반적인 구현은 ClassPathXmlApplicationContext, XMLWebApplicationContext 및 FileSystemxMlApplicationContext와 같은 XML 제품이라고 확신합니다. 그것들은 내가 사용한 유일한 세 가지입니다.

웹 앱을 개발하는 경우 xmlwebapplicationcontext를 사용해야한다고 말하는 것이 안전합니다.

콩이 스프링을 알고 싶다면 BeanFactoryAware 및/또는 ApplicationContextAware를 구현할 수 있으므로 BeanFactory 또는 ApplicationContext를 사용하여 구현할 인터페이스를 선택할 수 있습니다.

Answer 9

멍청한 그리고 ApplicationContext 둘 다 봄부터 콩을 얻는 방법입니다 IOC 컨테이너이지만 여전히 약간의 차이가 있습니다.

멍청한 많은 콩을 인스턴스화, 구성 및 관리하는 실제 컨테이너입니다. 이 콩은 일반적으로 서로 협력하므로 자체 사이에 종속성이 있습니다. 이러한 종속성은 BeanFactory가 사용하는 구성 데이터에 반영됩니다.

멍청한 그리고 ApplicationContext 둘 다 Java 인터페이스이며 ApplicationContext는 BeanFactory 확장됩니다. 두 가지 모두 XML 구성 파일을 사용하는 구성입니다. 간단히 말해서 기본적인 반전을 제공합니다.IOC) 및 의존성 주입 (DI) 기능은 ApplicationContext가 제공합니다 고급의 특징.

BeanFactory는 인터페이스로 표시됩니다. "org.springframework.beans.factory"Beanfactory가 여러 개의 구현이있는 곳.

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

차이점

1. 멍청한 전화 할 때 콩을 인스턴스화하십시오 getbean () 방법 컨테이너가 시작되면 ApplicationContext 인스턴트 싱글 톤 Bean 인스턴트를 인스턴스화하는 동안 getBean ()가 호출되기를 기다리지 않습니다.

2. 멍청한 국제화에 대한 지원은 아니지만 ApplicationContext 그것을 지원합니다.

3. 또 다른 차이점 멍청한 vs ApplicationContext 청취자로 등록 된 Bean에 이벤트를 게시하는 기능입니다.

4. 인기있는 구현 중 하나입니다 멍청한 인터페이스입니다 xmlbeanfactory 인기있는 구현 중 하나입니다 ApplicationContext 인터페이스입니다 classPathXmlApplicationContext.

5. 자동 배선 및 사용을 사용하는 경우 멍청한 등록 해야하는 것보다 autowiredbeanpostprocessor 사용중인 경우 XML로 구성 할 수있는 API 사용 ApplicationContext. 요약해서 말하자면 멍청한 테스트 및 비 생산 사용에 적합하지만 ApplicationContext 더 많은 기능이 풍부한 컨테이너 구현이며 선호해야합니다. 멍청한

6. 멍청한 기본적으로 지원 게으른 로딩 및 ApplicationContext 기본적으로 지원 공격적 로딩.

Answer 10

차이 멍청한 그리고 ApplicationContext 다음과 같이

1. BeanFactory는 게으른 초기화를 사용합니다 하지만 ApplicationContext는 열심 인 초기화를 사용합니다. BeanFactory의 경우 GetBeans () 메소드를 호출 할 때 Bean이 생성되지만 ApplicationContext 객체가 생성 된 경우 ApplicationContext의 경우 Bean이 선불로 작성됩니다.
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)beanFactory.getBean("triangle");

Answer 11

Bean Factory 대 응용 프로그램 컨텍스트의 특징 매트릭스 스프링 문서에서 공급됩니다

_{Beanfacotry 및 ApplicationContext 기능의 스크린 샷}

Answer 12

기본적으로 우리는 두 가지 방식으로 스프링 컨테이너 객체를 만들 수 있습니다.

1. BeatFactory 사용
2. ApplicationContext 사용

둘 다 인터페이스입니다

구현 클래스를 사용하여 스프링 컨테이너 용 객체를 만들 수 있습니다.

차이점에옵니다

멍청한

1. 주석 기반 종속성 주입을 지원하지 않습니다.

2. i18N을 지원하지 않습니다

3. 기본적으로 지지대 게으른 로딩

4. 여러 구성 파일로 구성 할 수 없습니다.

예 : BeanFactory 컨텍스트 = New XMLBeanFactory (New Resource ( "ApplicationContext.xml"));

ApplicationContext

1. 주석 기반 종속성 주입을 지원합니다 .-@autowired, @predestroy

2. I18N 지원

3. 기본적으로 Agpresive Loading을 지원합니다.

4. 여러 구성 파일을 구성 할 수 있습니다.

전:
ApplicationContext context = new ClassPathXmlApplicationContext ( "ApplicationContext.xml");

Answer 13

ㅏ. Bean Factory와 Application 컨텍스트의 한 가지 차이점은 GetBean () 메소드를 호출 할 때 이전의 인스턴스 인간 Bean이 컨테이너를 시작할 때 Singleton Bean을 인스턴스화하는 동안 이전의 인스턴스 인간 Bean이라는 것입니다. GetBean이 호출되기를 기다리지 않습니다.

비.

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

또는

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

프로젝트 요구 사항에 따라 하나 이상의 XML 파일을 사용할 수 있습니다. 여기에 두 개의 XML 파일을 사용하고 있기 때문에 DAO 클래스 용 서비스 클래스에 대한 구성 세부 사항은 하나입니다. 여기서 classPathXmlApplicationContext는 ApplicationContext의 자식입니다.

씨. BeanFactory 컨테이너는 기본 컨테이너이며 객체 만 생성하고 종속성을 주입 할 수 있습니다. 그러나 보안, 거래, 메시징 등과 같은 다른 서비스를 첨부하여 ApplicationContext 컨테이너를 사용해야하는 모든 서비스를 제공 할 수 없습니다.

디. BeanFactory는 국제화 IE I18N에 대한 지원을 제공하지 않지만 ApplicationContext는이를 지원합니다.

이자형. BeanFactory Container는 Autoscanning (지원 주석 기반 종속성 주입)의 기능을 지원하지 않지만 ApplicationContext 컨테이너는 지원됩니다.

에프. BeanFactory 컨테이너는 요청 시간까지 Bean 객체를 생성하지 않습니다. 그것은 콩의 컨테이너가 콩을 게으르게 적재한다는 것을 의미합니다. ApplicationContext 컨테이너는로드 할 때만 싱글 톤 Bean의 객체를 만듭니다. 조기 로딩이 있음을 의미합니다.

g. Beanfactory Container는 콩의 두 개의 스코프 (Singleton & Prototype) 만 지원합니다. 그러나 ApplicationContext 컨테이너는 모든 콩 범위를 지원합니다.

Answer 14

스프링 문서 에서이 문서를 참조하십시오.

http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/beans.html#context-intruction-ctx-vs-beanfactory

5.15.1 BeanFactory 또는 ApplicationContext?

그렇지 않은 이유가없는 한 ApplicationContext를 사용하십시오.

ApplicationContext에는 BeanFactory의 모든 기능이 포함되므로 메모리 소비가 중요 할 수 있고 몇 킬로바이트가 차이를 만들 수있는 애플릿과 같은 몇 가지 상황을 제외하고는 일반적으로 BeanFactory보다 권장됩니다. 그러나 대부분의 일반적인 엔터프라이즈 애플리케이션 및 시스템의 경우 ApplicationContext가 사용할 수있는 것입니다. Spring 2.0 이상은 BeanPostProcessor 확장 지점을 크게 사용합니다 (프록싱 등을 효과하기 위해). 평범한 멍청이 만 사용하는 경우 거래 및 AOP와 같은 상당한 양의 지원은 적어도 귀하의 추가 단계가 없으면 적용되지 않습니다. 이 상황은 실제로 구성에 문제가 없기 때문에 혼란 스러울 수 있습니다.

Answer 15

ApplicationContext는 Beanfactory의 빅 브라더이며 Beanfactory가 다른 많은 것들을 제공하는 모든 것입니다.

표준 org.springframework.beans.factory.beanfactory 라이프 사이클 기능, ApplicationContext 구현은 ApplicationContextAware Bean 및 ResourceLoaderAware, ApplicationEventPublisheraware 및 MessageSourceaware Bean을 감지하고 호출합니다.

Answer 16

실시간 시나리오에서 Spring IOC Core 컨테이너 (BeanFactory)와 Advanced J2EE 컨테이너 (ApplicationContext)의 차이는 다음과 같습니다.

1. BeanFactory는 Spring.xml 파일에 언급 된 Beans (즉, Pojo 클래스의 경우)에 대한 객체를 만듭니다.<bean></bean>) .getBean () 메소드를 호출 할 때만 ApplicationContext는 모든 콩에 대한 개체를 만듭니다.<bean></bean> Spring.xml 파일 자체를로드하면서 Spring.xml에서 "프로토 타입"으로 명시 적으로 언급되지 않은 경우).

2. beanfactory : (게으른 용기는 사용자/메인 클래스에서 명시 적으로 호출 할 때만 콩의 물체를 생성하기 때문에)

   /*
    * 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 파일 자체를로드하는 동안 모든 Singleton Bean의 객체를 생성하여 열렬한 컨테이너)

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

3. 기술적으로, ApplicationContext를 사용하면 실시간 애플리케이션에서는 서버 자체에서 응용 프로그램이 시작되는 동안 Bean 객체가 생성되므로 권장됩니다. 이렇게하면 객체가 이미 응답 할 수 있으므로 사용자 요청의 응답 시간이 줄어 듭니다.

Answer 17

봄 3 이후 공장을 만들고 싶다면 @configuration 주석이 적절한 것과 결합되었습니다 @scope

@Configuration
public class MyFactory {

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

공장은 @ComponentScan 주석 또는 XML 구성

Baeldung 사이트의 Spring Bean Scopes 기사

Answer 18

싱글 톤과 프로토 타입 콩 스코프 만 지원하기 때문에 비 WEB 애플리케이션에 BeanFactory를 사용하십시오.

ApplicationContext 컨테이너는 모든 Bean- 스코프를 지원하므로 웹 응용 프로그램에 사용해야합니다.

Answer 19

요약해서 말하자면:

그만큼 ApplicationContext BeanFactory의 모든 기능을 포함합니다. 일반적으로 전자를 사용하는 것이 좋습니다.

메모리 소비가 중요한 모바일 애플리케이션과 같은 제한된 상황이 있습니다.

이 시나리오에서는 더 경량을 사용하는 것이 정당화 될 수 있습니다. 멍청한. 그러나 대부분의 엔터프라이즈 응용 프로그램에서 ApplicationContext 당신이 사용하고 싶은 것입니다.

자세한 내용은 내 블로그 게시물을 참조하십시오.

Spring의 BeanFactory와 ApplicationContext의 차이 - The Basics의 Java Spring 블로그