BeanFactory와 ApplicationContext
나는 스프링 프레임 워크를 처음 접했고, 다가오는 회사 프로젝트에서 사용하기 위해 스프링 MVC를 평가할 목적으로 몇 가지 샘플 앱을 모아서 가지고 놀았습니다. 지금까지 나는 Spring MVC에서 보는 것을 정말 좋아하고, 사용하기가 매우 쉬우 며 테스트하기에 매우 적합한 클래스를 작성하도록 권장합니다.
실습과 마찬가지로 샘플 / 테스트 프로젝트 중 하나에 대한 주요 방법을 작성하고 있습니다. 나는 사이의 정확한 차이는 약 불분명 해요 한가지 BeanFactory과 ApplicationContext- 어떤 조건에서 사용하기 적합하다?
나는 그것이 ApplicationContextextends 이라는 것을 이해 BeanFactory하지만, 간단한 주요 메소드를 작성하는 경우 ApplicationContext제공 하는 추가 기능이 필요 합니까? 정확히 어떤 종류의 추가 기능을 ApplicationContext제공합니까?
"main () 메소드에서 사용해야하는"에 대한 답변 외에도 이러한 시나리오에서 어떤 구현을 사용해야하는지에 대한 표준 또는 지침이 있습니까? XML 형식으로 Bean / 응용 프로그램 구성에 따라 main () 메서드를 작성해야합니까? 안전한 가정입니까, 아니면 사용자를 특정 대상으로 잠그고 있습니까?
그리고이 답변은 웹 환경에서 변경 ApplicationContext됩니까? 내 클래스 중 하나가 Spring을 알고 있어야하는 경우 더 필요 할까요?
도움을 주셔서 감사합니다. 나는이 많은 질문이 참조 매뉴얼에서 대답 될 것임을 알고 있지만,이 두 인터페이스와 장단점을 사용하여 매뉴얼을 읽지 않고 각각의 장단점을 명확하게 분석하는 데 어려움을 겪고 있습니다.
스프링 문서는 이것에 훌륭합니다 : 3.8.1. BeanFactory 또는 ApplicationContext? . 그들은 비교가있는 테이블을 가지고 있습니다. 스 니펫을 게시합니다.
콩 공장
- 빈 인스턴스화 / 배선
응용 문맥
- 빈 인스턴스화 / 배선
- 자동 BeanPostProcessor 등록
- 자동 BeanFactoryPostProcessor 등록
- 편리한 MessageSource 액세스 (i18n 용)
- ApplicationEvent 간행물
따라서 응용 프로그램 컨텍스트 측에 제시된 사항이 필요하면 ApplicationContext를 사용해야합니다.
나에게 선택할 수있는 주요 차이점 BeanFactory이상은 ApplicationContext그 것 같다 ApplicationContext사전 인스턴스화 콩을 모두. 에서 봄 문서 :
Spring은 bean이 실제로 생성 될 때 속성을 설정하고 가능한 한 늦게 의존성을 해결합니다. 이것은 객체 또는 의존성 중 하나를 생성하는 데 문제가있는 경우 객체를 요청할 때 올바르게로드 된 Spring 컨테이너가 나중에 예외를 생성 할 수 있음을 의미합니다. 예를 들어, Bean은 누락되거나 유효하지 않은 특성으로 인해 예외를 발생시킵니다. 이로 인해 일부 구성 문제에 대한 가시성이 지연 될 수 있으므로 기본적으로 ApplicationContext 구현시 기본적으로 싱글 톤 Bean이 사전 설정됩니다. 이러한 Bean이 실제로 필요하기 전에 작성하는 데 약간의 선행 시간과 메모리가 필요하므로 나중에 ApplicationContext를 작성할 때 구성 문제를 발견 할 수 있습니다. 싱글 톤 Bean이 사전 인스턴스화되지 않고 지연 초기화되도록이 기본 동작을 계속 무시할 수 있습니다.
이를 감안할 때, 처음에는 BeanFactory격리 된 Bean을 테스트하기 위해 전체 애플리케이션을로드하지 않기 때문에 통합 / 성능 테스트에 사용 하기로 선택했습니다 . 그러나 내가 틀렸다면 누군가 나를 수정합니다 .XML 구성을 BeanFactory지원하지 않습니다 classpath. 그래서 BeanFactory및 ApplicationContext각 내가 원하는 중요한 기능을 제공하지만, 둘 모두 않았다.
내가 알 수 있듯이 기본 인스턴스화 동작을 재정의하는 것에 대한 문서의 메모는 구성에서 발생하며 빈마다이므로 XML 파일에서 "lazy-init"속성을 설정할 수는 없습니다. 테스트 용 버전과 배포 용 버전을 유지하지 못했습니다.
내가 한 일은 ClassPathXmlApplicationContext다음과 같이 테스트에 사용하기 위해 콩을 느리게로드하도록 확장 되었습니다.
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);
}
}
}
봄, 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콩은 전체 경로를 통해로드됩니다.ClassPathXmlApplicationContextCLASSPATH를 통해로드 된 BeanXMLWebApplicationContext와AnnotationConfigWebApplicationContext콩은 웹 애플리케이션 컨텍스트를 통해로드.AnnotationConfigApplicationContext주석 기반 구성에서 Spring Bean로드
예:
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(BeansConfiguration.class);
ApplicationContexta로 초기화 컨테이너ContextLoaderListener또는ContextLoaderServletA의 정의web.xml와ContextLoaderPlugin정의struts-config.xml.
참고 : XmlBeanFactory됩니다 되지 찬성 봄 3.1로 DefaultListableBeanFactory하고 XmlBeanDefinitionReader.
Miguel Ping이 답변 한 내용을 추가하기 위해 다음과 같은 문서의 다른 섹션 이 있습니다.
짧은 버전 : ApplicationContext를 사용하지 않는 이유가 없다면 ApplicationContext를 사용하십시오. 위의 권장 사항의 '그러나 왜'에 대해 약간 더 깊이를 찾는 사람들은 계속 읽으십시오.
(이 질문을 읽을 수있는 미래의 스프링 초보자를 위해 게시)
ApplicationContext보다 선호되는 방법입니다BeanFactory새로운 Spring 버전
BeanFactory은로 대체됩니다ApplicationContext. 그러나 여전히BeanFactory하위 호환성을 위해 존재합니다ApplicationContext extends BeanFactory다음과 같은 이점이 있습니다- 문자 메시지의 국제화를 지원합니다
- 등록 된 리스너에 대한 이벤트 공개를 지원합니다.
- URL 및 파일과 같은 리소스에 액세스
다른 사람이 이미 말한 것처럼 모바일 환경에 있지 않는 한 항상 ApplicationContext를 사용하는 것이 좋습니다. ApplicationContext는 더 많은 기능을 가지고 있으며 Spring 구성 파일을 단순화하는 데 도움이되는 RequiredAnnotationBeanPostProcessor, AutowiredAnnotationBeanPostProcessor 및 CommonAnnotationBeanPostProcessor와 같은 PostProcessors를 확실히 사용하고 싶어하며 Bean에서 @Required, @PostConstruct, @Resource 등의 주석을 사용할 수 있습니다 .
ApplicationContext가 제공하는 모든 것을 사용하지 않더라도 어쨌든 사용하는 것이 좋습니다. 나중에 메시지 또는 포스트 프로세서와 같은 일부 리소스를 사용하거나 트랜잭션 스키마를 추가하기 위해 다른 스키마를 사용하기로 결정한 경우 이미 ApplicationContext가 있으며 코드를 변경할 필요가 없습니다.
독립형 앱을 작성하는 경우 ClassPathXmlApplicationContext를 사용하여 기본 메소드에서 ApplicationContext를로드하고 기본 Bean을 가져 와서 run () (또는 기타 메소드)을 호출하여 앱을 시작하십시오. 웹 앱을 작성하는 경우 web.xml에서 ContextLoaderListener를 사용하여 ApplicationContext를 작성하고 나중에 JSP, JSF, JSTL, struts, Tapestry 등 사용 여부에 관계없이 ServletContext에서 가져올 수 있습니다. .
또한 여러 Spring 구성 파일을 사용할 수 있으며 생성자의 모든 파일을 나열하거나 ContextLoaderListener의 context-param에 파일을 나열하여 ApplicationContext를 만들거나 다음과 같은 기본 구성 파일을로드 할 수 있습니다 수입 명세서. <import resource = "otherfile.xml"/>를 사용하여 Spring 구성 파일을 다른 Spring 구성 파일로 가져올 수 있습니다.이 메소드는 기본 메소드에서 ApplicationContext를 프로그래밍 방식으로 작성하고 하나의 Spring 구성 파일 만로드 할 때 매우 유용합니다.
ApplicationContext : 스프링 구성 파일에 구성된 스프링 빈을로드하고 스프링 빈의 라이프 사이클을 관리하고 컨테이너 시작시 getBean ( "springbeanref") 가 호출 될 때까지 기다리지 않습니다 .
BeanFactory 스프링 구성 파일에 구성된 스프링 빈을로드하고 getBean ( "springbeanref")을 호출 할 때 스프링 빈의 수명주기를 관리합니다. 따라서 스프링 빈 수명주기 시작시 getBean ( "springbeanref") 을 호출 할 때 .
대부분의 경우, ApplicationContext는 모바일 애플리케이션에서와 같이 자원을 절약 할 필요가없는 한 선호됩니다.
XML 형식에 따라 확신 할 수 없지만 ApplicationContext의 가장 일반적인 구현은 ClassPathXmlApplicationContext, XmlWebApplicationContext 및 FileSystemXmlApplicationContext와 같은 XML입니다. 그것들은 내가 사용한 유일한 세 가지입니다.
웹 앱을 개발하는 경우 XmlWebApplicationContext를 사용해야한다고 말하는 것이 안전합니다.
Bean이 Spring을 인식하도록하려면 BeanFactoryAware 및 / 또는 ApplicationContextAware를 구현하도록 BeanFactory 또는 ApplicationContext를 사용하고 구현할 인터페이스를 선택할 수 있습니다.
BeanFactory 와 ApplicationContext는 모두 스프링 IOC 컨테이너 에서 빈을 얻는 방법 이지만 여전히 약간의 차이가 있습니다.
BeanFactory 는 다수의 Bean을 인스턴스화, 구성 및 관리하는 실제 컨테이너입니다. 이 Bean은 일반적으로 서로 협업하므로 서로간에 종속성이 있습니다. 이러한 종속성은 BeanFactory가 사용하는 구성 데이터에 반영됩니다.
BeanFactory 및 ApplicationContext는 모두 Java 인터페이스이며 ApplicationContext는 BeanFactory를 확장합니다. 둘 다 XML 구성 파일을 사용하는 구성입니다. 간단히 말해 BeanFactory는 기본적인 IoC (Inversion of Control ) 및 DI (Dependency Injection ) 기능을 제공하는 반면 ApplicationContext는 고급 기능을 제공 합니다.
BeanFactory는 " org.springframework.beans.factory " 인터페이스로 표현됩니다. 여기서 BeanFactory는 여러 구현이 있습니다.
ClassPathResource resource = new ClassPathResource("appConfig.xml");
XmlBeanFactory factory = new XmlBeanFactory(resource);
차
BeanFactory 는 컨테이너가 시작될 때 SingleBean Bean을 인스턴스화하는 동안 getBean () 메소드 를 호출 할 때 Bean을 인스턴스화합니다. getBean () 이 호출 되기를 기다리지 않습니다.
BeanFactory 는 국제화를 지원하지 않지만 ApplicationContext 는이를 지원합니다.
BeanFactory 와 ApplicationContext의 또 다른 차이점은 리스너로 등록 된 Bean에 이벤트를 공개하는 기능입니다.
의 인기 구현의 하나 의 BeanFactory 인터페이스입니다 은 XmlBeanFactory 의 인기 구현 한 동안 의 ApplicationContext 인터페이스는 ClassPathXmlApplicationContext가 .
자동 배선을 사용하고 BeanFactory 를 사용하는 경우 ApplicationContext를 사용하는 경우 XML로 구성 할 수있는 API를 사용하여 AutoWiredBeanPostProcessor 를 등록해야합니다 . 요약하면 BeanFactory 는 테스트 및 비 프로덕션 용도로는 괜찮지 만 ApplicationContext 는 기능이 풍부한 컨테이너 구현이며 BeanFactory 보다 선호되어야합니다.
BeanFactory 는 기본적으로 Lazy loading을 지원 하고 ApplicationContext 는 기본적으로 Aggregsive 로딩을 지원 합니다.
BeanFactory 와 ApplicationContext의 차이점 은 다음과 같습니다.
- BeanFactory는 지연 초기화를 사용 하지만 ApplicationContext는 열성적인 초기화를 사용합니다. BeanFactory의 경우, getBeans () 메소드를 호출하면 Bean이 작성되지만 ApplicationContext 오브젝트가 작성 될 때 ApplicationContext의 경우 Bean이 작성됩니다.
- 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");
Bean Factory의 기능 매트릭스 대 스프링 문서에서 제공되는 애플리케이션 컨텍스트
BeanFacotry 및 ApplicationContext의 기능 스크린 샷
기본적으로 우리는 두 가지 방법으로 스프링 컨테이너 객체를 만들 수 있습니다
- BeatFactory를 사용하여
- ApplicationContext 사용
둘 다 인터페이스입니다
구현 클래스를 사용하여 스프링 컨테이너에 대한 객체를 만들 수 있습니다
차이에오고
BeanFactory
주석 기반 종속성 인젝션을 지원하지 않습니다.
I18N을 지원하지 않습니다
기본적으로 지원 지연 로딩
여러 구성 파일로 구성 할 수 없습니다.
예 : BeanFactory context = 새로운 XmlBeanFactory (new Resource ( "applicationContext.xml"));
ApplicationContext
주석 기반 의존성 주입 지원-@Autowired, @PreDestroy
I18N 지원
기본적으로 Aggregsive 로딩을 지원합니다.
여러 구성 파일을 구성 할 수 있습니다.
예 :
ApplicationContext context = 새로운 ClasspathXmlApplicationContext ( "applicationContext.xml");
ㅏ. Bean 팩토리와 애플리케이션 컨텍스트의 한 가지 차이점은 getBean () 메소드를 호출 할 때 이전의 Bean 만 인스턴스화하는 반면 ApplicationContext는 컨테이너가 시작될 때 Singleton Bean을 인스턴스화한다는 점입니다. getBean이 호출되기를 기다리지 않습니다.
비.
ApplicationContext context = new ClassPathXmlApplicationContext("spring.xml");
또는
ApplicationContext context = new ClassPathXmlApplicationContext{"spring_dao.xml","spring_service.xml};
프로젝트 요구 사항에 따라 하나 이상의 xml 파일을 사용할 수 있습니다. 여기에 두 개의 XML 파일, 즉 dao 클래스에 대한 다른 서비스 클래스의 구성 세부 정보에 대한 하나의 xml 파일을 사용합니다. 여기서 ClassPathXmlApplicationContext는 ApplicationContext의 자식입니다.
씨. BeanFactory 컨테이너는 기본 컨테이너이며, 객체를 생성하고 의존성을 주입 할 수 있습니다. 그러나 ApplicationContext Container를 사용해야하는 모든 서비스를 제공하기 위해 보안, 트랜잭션, 메시징 등과 같은 다른 서비스를 연결할 수 없습니다.
디. BeanFactory는 국제화, 즉 i18n을 지원하지 않지만 ApplicationContext는이를 지원합니다.
이자형. BeanFactory 컨테이너는 AutoScanning (지원 주석 기반 종속성 주입) 기능을 지원하지 않지만 ApplicationContext 컨테이너는 지원합니다.
에프. Beanfactory Container는 요청 시간까지 Bean 객체를 생성하지 않습니다. 그것은 Beanfactory 컨테이너가 콩을 느리게로드한다는 것을 의미합니다. ApplicationContext 컨테이너는로드시에만 Singleton Bean의 오브젝트를 작성합니다. 조기로드가 있음을 의미합니다.
지. Beanfactory Container는 두 가지 범위 (싱글 톤 및 프로토 타입) 만 지원합니다. 그러나 ApplicationContext Container는 모든 Bean 범위를 지원합니다.
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가 제공하는 모든 것 외에도 많은 다른 것들을 제공합니다.
ApplicationContext 구현은 표준 org.springframework.beans.factory.BeanFactory 라이프 사이클 기능 외에도 ResourceLoaderAware, ApplicationEventPublisherAware 및 MessageSourceAware Bean뿐만 아니라 ApplicationContextAware Bean을 감지하고 호출합니다.
실시간 시나리오에서 Spring IOC Core 컨테이너 (BeanFactory)와 Advanced J2EE 컨테이너 (ApplicationContext)의 차이점은 다음과 같습니다.
BeanFactory는
<bean></bean>.getBean () 메소드를 호출 할 때만 spring.xml 파일 ()에 언급 된 Bean (예 : POJO 클래스)에 대한 오브젝트를 작성하지만 ApplicationContext는 모든 Bean에 대한 오브젝트를 작성합니다 (<bean></bean>범위가 아닌 경우). spring.xml 파일 자체를로드하는 동안 spring.xml에 구성된 "프로토 타입"으로 명시 적으로 언급 됨).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");기술적으로 ApplicationContext는 실시간 응용 프로그램에서 응용 프로그램이 서버 자체에서 시작되는 동안 만들어 지므로 권장됩니다. 객체가 이미 응답 할 수 있으므로 사용자 요청에 대한 응답 시간이 줄어 듭니다.
Spring 3 이후로 팩토리를 만들려면 @configuration주석과 적절한 주석을 사용할 수 있다고 언급 할 가치가 있다고 생각합니다.@scope
@Configuration
public class MyFactory {
@Bean
@Scope("prototype")
public MyClass create() {
return new MyClass();
}
}
@ComponentScan주석 또는 XML 구성을 사용하여 스프링 컨테이너에서 팩토리를 볼 수 있어야 합니다
웹 애플리케이션이 아닌 애플리케이션에 BeanFactory를 사용하십시오. Singleton 및 Prototype Bean 범위 만 지원하기 때문입니다.
ApplicationContext 컨테이너는 모든 Bean 범위를 지원하므로 웹 애플리케이션에 사용해야합니다.
요약하자면:
의 ApplicationContext는 BeanFactory의 모든 기능을 포함. 전자를 사용하는 것이 일반적으로 권장됩니다.
메모리 소비가 중요한 모바일 애플리케이션과 같은 일부 제한된 상황이 있습니다.
이 시나리오에서는 더 가벼운 BeanFactory 를 사용하는 것이 좋습니다. 그러나 대부분의 엔터프라이즈 응용 프로그램에서는 ApplicationContext 가 사용하려고합니다.
자세한 내용은 내 블로그 게시물을 참조하십시오.
Spring의 BeanFactory와 ApplicationContext의 차이점 – 기본 사항의 Java Spring 블로그
참고 URL : https://stackoverflow.com/questions/243385/beanfactory-vs-applicationcontext
'Programing' 카테고리의 다른 글
| 생성자 내에서 가상 함수 호출 (0) | 2020.04.25 |
|---|---|
| hashCode ()를 재정의하는 객체의 고유 ID를 얻는 방법은 무엇입니까? (0) | 2020.04.25 |
| Java에서 사전을 어떻게 작성합니까? (0) | 2020.04.25 |
| 활동 상황과 응용 상황의 차이 (0) | 2020.04.24 |
| Base64로 문자열을 인코딩하려면 왜 'b'가 필요합니까? (0) | 2020.04.24 |