스프링으로 전환하기, 스프링 컨테이너와 스프링 빈

스프링 핵심원리-기본편, 김영한님

수업을 듣고 정리한 글입니다.

https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard

스프링 핵심 원리 - 기본편 - 인프런 | 강의

 

지금까지는 순수한 java 코드로 DI를 적용했다. 이제 스프링을 사용해보자.

 

Spring 사용

@Configuration을 AppConfig에 붙이고 @Bean을 적어주자.

MemberApp에서 빈 가져오기

중요 코드

        ApplicationContext applicationContext = new AnnotationConfigApplicationContext(AppConfig.class);
        MemberService memberService = applicationContext.getBean("memberService", MemberService.class);

ApplicationContext에서 @Configuration인 AppConfig를 가져온다.

AppConfig의 memberService(메소드 이름)과 타입을 적어서 memberService를 가져온다.

 

 

로그를 보면 @Bean을 적은 스프링 빈들이 등록된 것을 볼 수 있다.

그리고 결과가 AppConfig와 같이 잘 나온다.(사진에는 없음)

 

OrderApp에서 빈 가져오기

 

스프링 컨테이너 ApplicationContext

기존에는 개발자가 AppConfig를 사용해서(AppConfig 객체를 만들어서) 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용한다.

ApplicationContext는 인터페이스이다. 

스프링 빈 @Bean

스프링 컨테이너는 @Configuration이 붙은 AppConfig를 설정 정보로 사용한다. @Bean이라고 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라 한다.

스프링 빈은 @Bean이 붙은 메서드의 명을 스프링 빈의 이름으로 사용한다.

스프링 컨테이너를 이용해 스프링 빈을 찾는다. 

applicationContext.getBean()

 

스프링 컨테이너 생성 과정

 

컨테이너에 등록된 빈 조회

모든 등록된 빈 출력하기

출력 결과

 

내가 만든 빈만 보고싶다면? => 애플리케이션 빈 출력하기

BeanDefinition을 확인하여 Role_APPLICATION이면 출력

Role ROLE_APPLICATION : 직접 등록한 애플리케이션 빈
Role ROLE_INFRASTRUCTURE : 스프링이 내부에서 사용하는 빈

 

출력 로그

 

스프링 빈 조회

memberService 객체가 잘 프린트된 것을 볼 수 있다.

 

이름으로 조회, 타입으로 조회

인터페이스가 아닌 구체 클래스의 인스턴스가 빈이 된다.

 

구체 타입으로 조회, 이름 없을때 조회(에러처리)

 

같은 타입으로 둘 이상 조회

타입으로 조회시 같은 타입의 스프링 빈이 둘 이상이면 오류 발생한다. 이때는 빈 이름을 지정하자.

 

같은 타입의 스프링 빈 두개 생성

Test이므로 파일안에 SameBeanConfig를 만든다.

 

컨테이너를 생성하여 테스트를 만든다.

로그

잘 출력되는 것을 볼 수 있다.

 

상속 관계

부모 타입으로 조회하면, 자식 타입도 함께 조회된다.

Object 타입 조회시 모든 스프링 빈 조회가능

 

Config 만들기

부모가 같은 자식 2개 빈을 만들었다.

 

조회하기

 

단축키

iter: for문 반복자 조회문 생성

soutv : variable 출력

부모 타입으로 조회시에 자식 빈들도 다 출력된다.

 

Object로 조회시엔 모든 빈이 다 출력된다. (Object: 모든 자바 객체의 가장 높은 조상님)

 

BeanFactory와 ApplicationContext

상속관계

BeanFactory

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

스프링 빈을 관리하고 조회하는 역할 담당 ex) getBean()

 

ApplicationContext

BeanFactory 모두 상속받는다 => BeanFactory 기능 + 애플리케이션 개발 시 여러 부가서비스

BeanFactory를 직접 사용할 일은 거의 없고 부가 기능이 포함된 ApplicationContext를 사용한다.

 

XML 설정

스프링 컨테이너는 지금까지 했던 java 코드 설정 외에도 XML 형식으로도 설정 정보를 받아들일 수 있다.

XML 장점

많은 레거시 프로젝트들이 XML로 되어있다.

컴파일없이 빈 설정 정보를 변경할 수 있다.

 

실습- 설정파일 만들기(xml)

리소스 파일에 AppConfig.xml 명으로 저장했다.

자바 코드와 형식이 매우 유사하다.

 

테스트 만들기

자바코드와 테스트 코드도 매우 유사하다. new로 호출하는 함수만 달라졌다.

 

테스트 실행

 

 

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

@Bean(자바코드), <bean> (xml) 당 각각 하나씩 메타 정보(BeanDefinition)이 생성된다.

즉 자바코드로 구현되든 xml로 구현되든 스프링은 똑같은 BeanDefinition을 만들기때문에 상관이 없다.

BeanDefinition으로 추상화

역할: BeanDefinition

구현: java, xml, Groovy 등등

 

이 다양한 설정파일을 읽기 위해 리더(Reader)가 존재한다 (자바코드 리더, xml 코드 리더, 등등)

리더(Reader)는 설정파일에 들어가서 코드를 읽고 그것을 바탕으로 BeanDefinition을 생성한다.

 

BeanDefinition 출력하기

 

빈 관련 메타정보가 출력되었다.

한번 읽어보기

 

BeanDefinition을 실제로 만들어 등록할 수 있지만, 실무에서는 거의 그럴일은 없다.

 

스프링 등록 - 1. 직접 등록

                  -  2. 팩토리 빈으로 등록(AppConfig)