ApplicationContext 정리 - 스프링 핵심원리 기본편

//스프링 컨테이너 생성
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);

ApplicationContext 를 스프링 컨테이너라 한다.

ApplicationContext 는 인터페이스이다.

스프링 컨테이너는 XML을 기반으로 만들 수 있고, 애노테이션 기반의 자바 설정 클래스로 만들 수 있다.

직전에 AppConfig 를 사용했던 방식이 애노테이션 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것

이 클래스는 ApplicationContext 인터페이스의 구현체이다.

 

스프링 컨테이너의 생성 과정

1. 스프링 컨테이너 생성 

 

2. 스프링 빈 등록

3. 스프링 빈 의존관계 설정 - 준비

 

4. 스프링 빈 의존관계 설정 - 완료 

 

BeanFactory와 ApplicationContext 

 

BeanFactory

스프링 컨테이너의 최상위 인터페이스다.

스프링 빈을 관리하고 조회하는 역할을 담당한다.

getBean() 을 제공한다.

지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능이다.

 

ApplicationContext

BeanFactory 기능을 모두 상속받아서 제공한다.

빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데, 그러면 둘의 차이가 뭘까?

애플리케이션을 개발할 때는 빈은 관리하고 조회하는 기능은 물론이고, 수많은 부가기능이 필요하다.

 

 

정리

ApplicationContext는 BeanFactory의 기능을 상속받는다.

ApplicationContext는 빈 관리기능 + 편리한 부가 기능을 제공한다.

BeanFactory를 직접 사용할 일은 거의 없다.

부가기능이 포함된 ApplicationContext를 사용한다.

BeanFactory나 ApplicationContext를 스프링 컨테이너라 한다.

 

다양한 설정 형식 지원 - 자바 코드, XML

스프링 컨테이너는 다양한 형식의 설정 정보를 받아드릴 수 있게 유연하게 설계되어 있다.

자바 코드, XML, Groovy 등등

 

애노테이션 기반 자바 코드 설정 사용 

new AnnotationConfigApplicationContext(AppConfig.class)

AnnotationConfigApplicationContext 클래스를 사용하면서 자바 코드로된 설정 정보를 넘기면 된다.

 

XML 설정 사용

최근에는 스프링 부트를 많이 사용하면서 XML기반의 설정은 잘 사용하지 않는다.

아직 많은 레거시 프로젝트 들이 XML로 되어 있고, 또 XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점

GenericXmlApplicationContext 를 사용하면서 xml 설정 파일을 넘기면 된다.

 

import static org.assertj.core.api.Assertions.*;

public class XmlAppContext {
 	@Test
 	void xmlAppContext() {
 	ApplicationContext ac = new
	GenericXmlApplicationContext("appConfig.xml");

 	MemberService memberService = ac.getBean("memberService",
	MemberService.class);
 	assertThat(memberService).isInstanceOf(MemberService.class);
 }
}

xml 기반의 스프링 빈 설정 정보

xml 기반으로 설정하는 것은 최근에 잘 사용하지 않음.

 

스프링 빈 설정 메타 정보 - BeanDefinition

 

 

 

스프링은 어떻게 이런 다양한 설정 형식을 지원하는 것일까?

그 중심에는 BeanDefinition 이라는 추상화가 있다.

 

XML을 읽어서 BeanDefinition을 만들면 된다.

자바 코드를 읽어서 BeanDefinition을 만들면 된다.

스프링 컨테이너는 자바 코드인지, XML인지 몰라도 된다.

오직 BeanDefinition만 알면 된다.

BeanDefinition 을 빈 설정 메타정보라 한다.

 

@Bean ,<bean> 당 각각 하나씩 메타 정보가 생성된다.

스프링 컨테이너는 이 메타정보를 기반으로 스프링 빈을 생성한다.

 

AnnotationConfigApplicationContext 는 AnnotatedBeanDefinitionReader 를 사용해서 AppConfig.class 를 읽고 BeanDefinition 을 생성한다.

GenericXmlApplicationContext 는 XmlBeanDefinitionReader 를 사용해서 appConfig.xml 설정 정보를 읽고

BeanDefinition 을 생성한다.

새로운 형식의 설정 정보가 추가되면, XxxBeanDefinitionReader를 만들어서 BeanDefinition 을 생성하면 된다.

 

참고 - 스프링 컨테이너를 생성하면서 스프링 빈 등록하기

스프링 컨테이너는 생성자에 클래스 정보를 받는다.

여기에 클래스 정보를 넘기면 해당 클래스가 스프링 빈으로 자동 등록된다.

new AnnotationConfigApplicationContext(AutoAppConfig.class,DiscountService.class);

 

자동, 수동의 올바른 실무 운영 기준

, 스프링이 나오고 시간이 갈 수록 점점 자동을 선호하는 추세.

@Component 뿐만 아니라 @Controller , @Service , @Repository 처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다. 거기에 더해서 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고, 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계함.

 

-> 설정 정보를 기반으로 애플리케이션을 구성하는 부분과 실제 동작하는 부분을 명확하게 나누는 것이 이상적이지만, 개발자 입장에서 스프링 빈을 하나 등록할 때 @Component 만 넣어주면 끝나는 일

 

그러면 수동 빈 등록은 언제 사용하면 좋을까?

 

업무 로직 빈: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.

 

기술 지원 빈: 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다

 

업무 로직 빈 : 자동 기능을 적극 사용

기술 지원 로직 : 애플리케이션에 광범위하게 영향을 미치므로, 수동 빈으로 등록해서 설정 정보에 바로 나타나는 것이 유지보수에 좋음.

 

정리 편리한 자동 기능을 기본으로 사용하자

직접 등록하는 기술 지원 객체는 수동 등록