[Spring 기본] 4. 스프링 컨테이너와 스프링 빈🫛

안녕하세요!

오늘부터 본격적으로 스프링의 세계로 들어가볼까 합니다.

고고씽!!

---

1. 스프링 컨테이너 생성

먼저 스프링 컨테이너가 생성되는 과정을 알아보도록 하겠습니다.

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

저번 섹션 마지막 쯔음에 나왔던 코드입니다.

new로 해서 AnnotationConfigApplicationContext 이름도 긴 이 객체를 생성하면서 AppConfig를 파라미터(매개변수)로 넘겼습니다.

이렇게 하면 반환값으로 ApplicationContext가 나옵니다.

 

이 ApplicationContext를 스프링 컨테이너라고 하고, 인터페이스입니다.

다형성이 적용되어있는 것입니다.

이 ApplicationContext 인터페이스를 구현한 것 중에 하나가 AnnotationConfigApplicationContext 입니다.

=> AnnotationConfigApplicationContext(AppConfig.class) 이 클래스는 ApplicationContext 인터페이스의 구현체

 

스프링 컨테이너는 XML 기반으로 만들 수 있고, Annotation 기반의 자바 설정 클래스로 만들 수도 있습니다.

(요즘은 XML 기반으로 만드는 것을 잘 사용하지 않습니다.)

저번 섹션에서 AppConfig를 사용했던 방식이 Annotation 기반의 자바 설정 클래스로 스프링 컨테이너를 만든 것입니다.

 

<참고✔️>
더 정확히는 스프링 컨테이너를 부를 때 BeanFactory, ApplicationContext로 구분해서 얘기합니다.
BeanFactory를 직접 사용하는 경우는 거의 없으므로, 일반적으로 ApplicationContext를 스프링 컨테이너라고 합니다.
이 부분은 뒤에서 다룰 예정입니다.

 

1-1. 스프링 컨테이너 생성 과정

1-1(1). 스프링 컨테이너 생성

스프링 컨테이너 생성

1. new AnnotationConfigApplicationContext(AppConfig.class)라고 하면서 AppConfig의 정보를 줍니다.

2. 그러면 스프링 컨테이너가 딱 만들어집니다.

    그런데, 이 스프링 컨테이너 안에는 스프링 빈 저장소라는 것이 있습니다.

    그래서, key는 빈 이름이 되고, 값은 빈 객체가 되는 것입니다.

    => 스프링 컨테이너를 생성할 때는 구성 정보를 지정해줘야 합니다.

여기서는 AppConfig.class를 구성 정보로 지정했습니다.

 

1-1(2). 스프링 빈 등록🫛

스프링 빈 등록

스프링 컨테이너가 본인을 생성하면서 스프링 빈 저장소에 스프링 빈을 등록합니다.

어떻게 하냐면...

1. AppConfig.class 설정 정보를 넘긴 것에서 @Bean 붙은 것을 하나씩 봅니다.

2. 그리고 @Bean 붙은 것을 다 호출합니다.

   호출해보니까 memberService라는 메서드 이름이 있네요? 이 메서드 이름을 key(빈 이름)로 등록합니다.

   이 key에 대한 값은 return 해서 new로 반환하는 객체를 빈 객체로 등록을 해줍니다. 

3. 지금 그림에 나와있는 것은 총 4개니까 이 4개를 다 등록해줍니다.

   그러면 new한 인스턴스 객체 4개가 다 등록이 되고, 이것을 스프링 빈이라고 합니다.

<참고✔️>
- 빈 이름은 베서드 이름을 사용합니다.
- 빈 이름을 직접 부여할 수도 있습니다.
=> @Bean (name = "memberService2")

<주의!!⚠️>
빈 이름은 항상 다른 이름을 부여해야 합니다.
같은 이름을 부여하면, 다른 빈이 무시되거나 기존 빈을 덮어버립니다.
이러면 설정에 따라 오류가 발생합니다.

 

1-1(3). 스프링 빈 의존관계 설정 - 준비🫛

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

스프링 빈은 초록색 타원의 그림으로 표현하도록 하겠습니다. (콩이어서..?ㅋㅋㅋ🫛)

이렇게 준비를 해놓고, 다음 단계로 넘어가보겠습니다.

 

1-1(4). 스프링 빈 의존관계 설정 - 완료🫛

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

의존관계를 넣어볼건데요.

memberService의 의존관계로는 memberRepository를 넣어줬습니다. (빨간색 화살표 참고)

이렇게 의존관계가 되면 new로 MemoryMemberRepository가 리턴이 됩니다. (코드 참고)

 

그 다음에 orderService를 보도록 하겠습니다.

orderService는 memberRepository도 의존하고 (빨간색 화살표), discountPolicy도 의존합니다 (파란색 화살표).

그래서, 이 discountPolicy 스프링 빈은 실제로는 new로 RateDiscountPolicy가 리턴이 됩니다.

 

동적인 객체 인스턴스 의존관계를 실제로 스프링이 다 연결해줍니다.

그럼 실제로 스프링 빈이 딱 연결이 됩니다.

 

스프링 컨테이너는 설정 정보를 참고하여 의존관계를 주입(DI)합니다.

단순히 자바 코드를 호출하는 것 같지만 차이가 있습니다.

이 차이는 뒤에 싱글톤 컨테이너에서 볼 예정입니다.

<참고✔️>
스프링 빈을 생성하고 의존관계를 주입하는 단계가 나누어져 있습니다.
그런데 이렇게 자바 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한 번에 처리가 됩니다.
여기서는 이해를 돕기 위해 개념적으로 나누어져 있고, 자세한 내용은 의존관계 자동 주입에서 다시 나올 예정입니다.

<정리✏️>
스프링 컨테이너를 생성하고, 설정(구성) 정보를 참고해서 스프링 빈도 등록하고, 의존관계도 설정했습니다.
이제 스프링 컨테이너에서 데이터를 조회해보겠습니다.

---

2. 컨테이너에 등록된 모든 빈 조회

스프링 컨테이너에 실제 스프링 빈들이 잘 등록되었는지 확인해보도록 하겠습니다.

이건 테스트 코드로 한 번 짜보도록 하겠습니다.

우선 test에서 hello.core에 beanfind라는 패키지를 만들어보겠습니다.

그리고, 이 beanfind라는 패키지 안에 ApplicationContextInfoTest라는 자바 클래스를 만들어보겠습니다.

만들면 이런 파일 구조가 나옵니다.

 

테스트 코드를 한 번 짜보겠습니다.

public class ApplicationContextInfoTest {

    //너무 길어서 ac로 줄였습니다.
    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("모든 빈 출력하기")
    void findAllBean() {
        //ac.getBeanDefinitionNames(); 까지 치고 Ctrl + Alt + V 하면 앞에 타입 하고 나옵니다.
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        //리스트나 배열이 있으면 iteration이라고 해서 iter 치고 Tab 누르면 밑에 for문이 나옵니다.
        for (String beanDefinitionName : beanDefinitionNames) {
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println("name = " + beanDefinitionName + " object = " + bean);

        }
    }
}

첫 문장부터 차근차근 봐보겠습니다.

함수명은 ApplicationContextInfoTest로 지었습니다.

public 써 있는데, JUnit5에서부터는 앞에 public 안 붙혀도 됩니다.

(생략 가능한데 일단 이거 얘기하려고 적어놓은 것입니다.)

 

AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);를 통해서 스프링 컨테이너를 생성했습니다. 위에서도 봤던 내용입니다.

변수명은 너무 길어서 ac로 줄였습니다.

 

"모든 빈 출력하기"로 해서 findAllBean으로 함수 이름을 지어보았습니다.

void 앞에 public도 위에서 얘기한 이유로 생략한 것입니다.

 

String[] beanDefinitionNames = ac.getBeanDefinitionNames(); 이 코드에서 이 앞에 붙은 String 타입.. 사실 왜 쓰였는지 모릅니다.

ac.getBeanDefinitionNames()치고 Window 기준 Ctrl + Alt + V 치면 위에처럼 타입이 나옵니다.

어떤 타입이 리턴 되는지 알아볼 필요가 없다는 장점이 있죠.

위의 ac.getBeanDefinitionNames()는 스프링에 등록된 모든 빈 이름을 조회합니다.
그리고, ac.getBean()은 빈 이름으로 빈 객체(인스턴스)를 조회합니다.

 

암튼 왜 앞에 Object랑 String이 오는지는 스프링을 만든 사람이 이렇게 설계를 해 버린 것이어서 확실하게는 모르겠지만...

getBeanDefinitionNames는 이름들이 오고, 이름은 String이죠. 여러 개의 String들이라 String 배열을 사용한 것이 아닐까 조심스레 예측해봅니다...

 

그 다음 for문을 봐보도록 하겠습니다.

사실 이 for문... 위에 리스트나 배열이 있으면 iteration이라고 해서 iter 치고, Tab 누르면 이렇게 for문이 나옵니다.

그리고, Object bean = ac.getBean(beanDefinitionName);도 위에 String때와 같이 Ctrl + Alt + V 치면 타입을 알려줍니다.

 

테스트를 실행해보겠습니다.

모든 빈 출력

스프링 컨테이너에 등록된 모든 빈이 이렇게 쫘라락 출력이 되었습니다.

위에 5줄은 뒤에가 짤리긴 했지만, 위에 5줄은 스프링이 내부적으로 스프링 자체를 확장하기 위해서 쓰는 기반 빈들입니다.

참고로 appConfig도 스프링 빈으로 등록이 됩니다.

그리고, 아래 4줄이 진짜 등록한 애들입니다.

 

근데, 내부적인 것들이랑 내가 짠 코드들이랑 섞이면 쫌 그럴 수 있잖아요..ㅎ 아무래도 본인이 짠 코드만 보고 싶을 수도 있습니다.

저는 그렇거든요.

그래서 applicationbean이라는 것을 한 번 출력해보도록 하겠습니다.

@Test
    @DisplayName("애플리케이션 빈 출력하기")
    void findApplicationBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);

            if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
                Object bean = ac.getBean(beanDefinitionName);
                System.out.println("name = " + beanDefinitionName + " object = " + bean);
            }
        }
    }

위에 코드랑 비슷한데, 딱 한 줄 다른 부분이 있습니다.

애플리케이션 빈을 출력하기 위해 if문을 사용해서 역할을 Application으로 잡았습니다.

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

 

테스트를 실행해보도록 하겠습니다.

애플리케이션 빈 출력

이렇게 제가 작성한 코드만 나오는 것을 볼 수 있습니다.

---

3. 스프링 빈 조회

3-1. 기본

스프링 컨테이너에서 스프링 빈을 찾는 가장 기본적인 조회 방법은 ac.getBean(빈 이름, 타입)입니다.

빈 이름을 생략하고, ac.getBean(타입)처럼 타입만 줘도 됩니다.

 

그런데, 조회 대상 스프링 빈이 없을 수도 있습니다. 이럴 때는 예외가 발생하는데요.

NoSuchBeanDefinitionException: No bean named 'xxxxx' available 라는 오류가 발생합니다.

 

그럼 코딩을 직접 한 번 해보겠습니다.

먼저, Test 패키지에서 hello.core 안에 있는 beanfind 패키지에 ApplicationContextBasicFindTest 클래스를 만들어줍니다.

 

우선, 빈 이름으로 조회해보겠습니다.

class ApplicationContextBasicFindTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByName() {
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }
}

맨 위에 public은 생략하였습니다.

getBean(빈 이름="memberService", 타입=MemberService.class)를 통해 조회했습니다.

Assertions를 통해 검증을 하였으며, Static 메서드 추가를 통해 Assertions를 생략하였습니다.

isInstanceOf는 데이터가 같은지 검증할 때 사용합니다.

Assertions 부분에서 isInstanceOf(MemberServiceImpl.class)에서 MemberServiceImpl 대신에 인터페이스인 MemberService가 와도 테스트는 잘 작동합니다.

 

테스트를 해보겠습니다.

빈 이름으로 조회

성공적으로 테스트가 되었다는 것을 알 수 있습니다.

 

이번엔 이름 없이 타입으로만 조회해보도록 하겠습니다.

@Test
    @DisplayName("이름 없이 타입으로만 조회")
    void findBeanByType() {
        MemberService memberService = ac.getBean(MemberService.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

아까 getBean(타입=MemberService.class) 여기에서 이름이 생략되었다는 것을 알 수 있습니다.

타입으로만 조회하는 것이기 때문에 이름을 적지 않은 것입니다.

여기에서도 isInstanceOf를 사용해 데이터가 같은지 검증을 했습니다.

 

테스트를 해보겠습니다.

이름 없이 타입으로만 조회

역시 테스트가 잘 진행된 것을 볼 수 있습니다.

 

이렇게 인터페이스로 조회를 하면 인터페이스의 구현체가 조회 대상이 됩니다.

그런데, 이것을 구체 타입으로 조회를 할 수도 있습니다.

@Test
    @DisplayName("구체 타입으로 조회")
    void findBeanByName2() {
        MemberService memberService = ac.getBean("memberService", MemberServiceImpl.class);
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
    }

MemberService memberService = ac.getBean("memberService", MemberServiceImpl.class);에서 타입 부분인 MemberServiceImpl 부분이 위에서는 MemberService로 적었지만, 여기에서는 구현체인 MemberServiceImpl로 적었다는 차이점이 있습니다.

 

테스트를 실행해보겠습니다.

구체 타입으로 조회

잘 실행되는 것을 알 수 있습니다.

 

이걸 왜 얘기했는지에 관해서 설명하기 위해 AppConfig로 이동해보겠습니다.

public MemberService memberService() {
        return new MemberServiceImpl(memberRepository());
    }

타입을 MemberService로 했기 때문에 꼭 MemberService로 해야하는 것이 아닙니다.

왜냐하면, 스프링 빈에 등록된 인스턴스 타입을 보고 결정하기 때문에 꼭 인터페이스여야 하는 것이 아니고 그 인터페이스의 구현체여도 상관이 없습니다.

몰론, 구체적으로 적는 것은 좋지 않습니다.

항상 역할과 구현을 구분해야하고, 역할에 의존하도록 해야 하기 때문입니다.

위의 코드들은 구현에 의존하고 있습니다.

 

항상 코드를 구현할 때는 실패하는 코드도 만들어야 합니다.

@Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByNameX() {
        //ac.getBean("XXXXX", MemberService.class);
        MemberService XXXXX = ac.getBean("XXXXX", MemberService.class);
    }

우선 검증과정 없이 해보겠습니다.

실제 저희가 구현하지 않은 이름인 XXXXX를 조회해보겠습니다.

과연 결과는 어떻게 나올까요?

빈 이름으로 조회 실패하는 테스트

실패합니다.

NoSuchBeanDefinitionException이라는 예외가 터지면서 XXXXX라는 이름의 빈이 존재하지 않는다고 합니다. 당연한 사실이죠. 저희는 이런거 구현한 적이 없으니까요~~

 

이번에는 검증 코드를 추가해서 검증을 해보도록 하겠습니다.

@Test
    @DisplayName("빈 이름으로 조회")
    void findBeanByNameX() {
        //ac.getBean("XXXXX", MemberService.class);
        //MemberService XXXXX = ac.getBean("XXXXX", MemberService.class);
        Assertions.assertThrows(NoSuchBeanDefinitionException.class, 
                () -> ac.getBean("XXXXX", MemberService.class);
    }

위의 Assertions는 평상시의 Assertions과 달리 JUnit의 Assertions입니다.

assertThrows를 사용하기 위해서는 JUnit거로 해야하더라구요.

assertThrows는 화살표 함수가 실행될 때, 왼쪽 인자로 넣은 에러 Exception이 터지는지 검사하는 메서드 입니다.

위에처럼 똑같이 static import를 해서 Assertions를 생략해도 됩니다.

에러가 터지면 테스트가 성공합니다.

 

테스트를 실행해보겠습니다.

에러가 터져야 테스트 성공

에러가 터져서 테스트가 성공했습니다.

 

기억해야 할 것은 구체타입으로 구현하면 유연성이 떨어진다는거...

왠만하면 역할(인터페이스)로 하세요~~

3-2. 동일한 타입이 둘 이상

타입으로 조회를 할 때, 같은 타입의 스프링 빈이 2개 이상이면 오류가 발생합니다.

어? 뭘 선택해야하지..??

이 때는 빈 이름을 지정하면 됩니다.

ac.getBeansOfType()을 사용하면 해당 타입의 모든 빈을 조회할 수 있습니다.

 

한 번 조회를 해보겠습니다.

우선, test 패키지에서 hello.core의 beanfind 패키지에서 ApplicationContextSameBeanFindTest라는 자바 클래스를 만들어줍니다.

public class ApplicationContextSameBeanFindTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(SameBeanConfig.class);
    
    @Test
    @DisplayName("타입으로 조회 시 같은 타입이 둘 이상 있으면 중복 오류 발생")
    void findBeanByTypeDuplicate() {
        MemberRepository bean = ac.getBean(MemberRepository.class);
    }
    //static: 이 클래스 안에서만 사용하려고 static 사용
    @Configuration
    static class SameBeanConfig {
        
        //빈 이름이 다른데 객체 인스턴스 타입이 같을 수도 있습니다.
        @Bean
        public MemberRepository memberRepository1() {
            return new MemoryMemberRepository();
        }
        
        @Bean
        public MemberRepository memberRepository2() {
            return new MemoryMemberRepository();
        }
    }
}

AppConfig를 귀찮게 또 손 대기 뭐시기하니까 이 클래스 안에서 SameBeanConfig를 만들었습니다.

우선 호출하는 방식은 위에서 했던 거랑 비슷합니다.

ac.getBean(MemberRepository.class);를 해서 MemberRepository.class의 빈을 호출합니다.

 

그런데, 위에와 차이점은 밑에 SameBeanConfig를 만들어서 이 AppConfig를 이용했고, 여기 클래스 안에 memberRepository1, memberRepository2 2개의 빈(빈 이름)을 만들었습니다.

SameBeanConfig 클래스는 이 클래스 안에서만 사용할 것이기 때문에 static을 사용했습니다.

여기 안에서 타입은 중복된 MemberRepository입니다.

 

<과정>

1. 이렇게 되면 스프링 컨테이너가 뜰 때, 이 SameBeanConfig만 가지고 실행됩니다.

2. 여기에는 스프링 컨테이너가 스프링 빈 memberRepository1, memberRepository2 2개를 등록합니다.

3. 이것을 돌려보면 memberRepository가 2개가 튀어나올 것입니다.

    2개 다 타입이 MemberRepository로 중복되기 때문입니다.

4. 그럼 스프링 입장에선 뭘 선택해야하지..? 합니다. 그러고 NoUniqueBeanDefinitionException이라는 예외가 터질 것입니다.

 

테스트를 실행해보겠습니다.

동일한 타입이 둘 이상

위에서 얘기한 그대로네요. 예외가 터졌습니다.

테스트 해보고 실패 결과 쫘라락 봐보면 어디서 문제가 생겼는지 알 수 있습니다.

친절하게 memberRepository1, memberRepository2 중 뭘 선택해야할지 모르겠다 대충 이런 뉘앙스로 오류가 뜨는 것을 알 수 있습니다.

 

테스트의 완성 단계는 검증 단계이기 때문에 Assertions를 마저 추가해보도록 하겠습니다.

 @Test
    @DisplayName("타입으로 조회 시 같은 타입이 둘 이상 있으면 중복 오류 발생")
    void findBeanByTypeDuplicate() {
        //MemberRepository bean = ac.getBean(MemberRepository.class);
        assertThrows(NoUniqueBeanDefinitionException.class,
                () -> ac.getBean(MemberRepository.class));
    }

위에처럼 에러 관련이기 때문에 JUnit의 Assertions를 사용했고, 거기서 assertThrow를 사용했습니다.

static import 하는 방법은 전에도 얘기했었는데, assertThrows만 있는 상태에서 빨간색으로 뜨면 거기서 저 static 메서드 가져오기를 누르거나 Assertions에서 Alt+Enter를 치면 됩니다.

중복 예외이기 때문에 위에서 얘기한 NoUniqueBeanDefinitionException을 사용했고, 타입은 MemberReporitory이기에 MemberRepository.class를 적어줬습니다.

 

테스트를 다시 실행해보겠습니다.

예외가 터져야 성공하는 로직입니다.

에러가 터져야 테스트 성공

역시나 테스트 성공했습니다.

 

그럼 빈 이름 지정을 통해 예외 상황을 해결해보도록 하겠습니다.

또 테스트 코드를 짜보도록 하겠습니다.

@Test
    @DisplayName("타입으로 조회 시 같은 타입이 둘 이상 있으면 빈 이름 지정을 통해 해결")
    void findBeanByName() {
        MemberRepository memberRepository = ac.getBean("memberRepository1", MemberRepository.class);
        assertThat(memberRepository).isInstanceOf(MemberRepository.class);
    }

빈 이름을 memberRepository1으로 지정해서 해결을 시도했습니다.

isInstanceOf는 위에서도 설명했다시피 데이터가 같은지 검증할 때 사용합니다.

assertThat(memberRepository)를 치고서 Alt+Enter를 치고 static import를 할 때, 사진처럼 1번째 것을 고르면 됩니다.

 

테스트를 실행해보겠습니다.

빈 이름 지정을 통해 같은 타입 중복 호출 해결

 

이번에는 특정 작업을 모두 조회해보겠습니다.

@Test
    @DisplayName("특정 타입을 모두 조회하기")
    void findAllBeanByType() {
        //String=Key, MemberRepository=Value
        Map<String, MemberRepository> beansOfType = ac.getBeansOfType(MemberRepository.class);
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key + " value = " + beansOfType.get(key));
        }
        System.out.println("beansOfType = " + beansOfType);
        assertThat(beansOfType.size()).isEqualTo(2);
    }

스프링에서 getBeansOfType() 함수의 Return형을 Map으로 구현해놨기 때문에 Map 함수가 사용되었습니다.

또, for (String key : beansOfType.keySet()) 여기는 beansOfType 변수가 Map<String, MemberRepository>라는 타입이었는데, 여기서 keySet()을 하면 <String, MemberRepository>에서의 앞 데이터인 String 데이터들만 가져올 수 있습니다.

 

더 쉽게 설명해보겠습니다.

beansOfType이라는 변수는 위의 사진과 같이 2개의 값이 있습니다.

각각의 하나 값이 String, MemberRepository 형의 데이터 2개를 갖고 있는 것입니다.

.keySet을 하면 앞쪽에 있는 key 값들로만 해서 배열을 만들어줍니다.

그러면 for문을 통해 빈 이름을 하나하나 출력해줄 수 있습니다.

그리고, .size는 사진처럼 Map의 데이터가 몇 개가 있나 확인하는 것입니다.

MemoryMemberRepository와 DbMemberRepository 2개가 나와야 하기에,

2개가 맞게 나오는지 Assertions의 assertThat으로 확인해주는 것입니다,

 

Q. 그럼 여기서 질문! 배열과 Map 함수의 차이점은 뭘까요?

배열

배열은 사진처럼 데이터 하나 당 한 데이터가 있습니다.

근데, Map은 한 데이터 당 key와 value라는 2개의 값으로 이루어져 있습니다.

사실 근데 배열과 Map은 비슷합니다.

Map 함수는 Key와 Value를 한 쌍으로 저장하는 객체고, 배열은 하나하나의 데이터를 저장하는 객체입니다.

둘 다 저장하는 애들이에요~~

 

그럼 다시 본론으로 들어가서... 테스트를 실행해보겠습니다.

특정 타입을 모두 조회하기

테스트가 잘 작동합니다.

3-3. 상속 관계

여기가 스프링 빈 조회 중에 제일 중요한 부분입니다.

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

그래서, 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면 모든 스프링 빈을 조회할 수 있습니다.

(눈에는 안 보이지만 기본적으로 다 extends Object가 있습니다.)

Test 패키지의 hello.core 안에 있는 beanfind 패키지에 ApplicationContextExtendsFindTest 자바 클래스를 추가해보도록 하겠습니다.

@Configuration
    static class TestConfig {
        @Bean
        public DiscountPolicy rateDiscountPolicy() {
            return new RateDiscountPolicy();
        }
        
        @Bean
        public DiscountPolicy FixDiscountPolicy() {
            return new FixDiscountPolicy();
        }
    }

위에처럼 AppConfig 건들기 쫌 귀찮아지기 때문에 이 클래스 안에 따로 테스트 Config를 만듭니다.

보면 타입은 DiscountPolicy로 같습니다. 타입이 중복되죠.

 

DiscountPolicy 타입 자리에 사실 각각 RateDiscountPolicy와 FixDiscountPolicy가 와도 됩니다.

근데, 왜 DiscountPolicy로 썼을까요?

그 이유는 역할과 구현을 항상 쪼개야하기 때문입니다. 구체화가 아닌 추상화로 해야 의존관계 주입을 할 때도 훨씬 코드가 보기 좋아지기 때문입니다.

몰론, 구체화 타입을 써도 문제는 없습니다.

 

테스트 코드를 마저 짜보겠습니다.

public class ApplicationContextExtendsFindTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext();

    @Test
    @DisplayName("부모 타입으로 조회 시, 자식이 둘 이상 있으면 중복 오류가 발생합니다.")
    void findBeanByParentTypeDuplicate() {
        //DiscountPolicy bean = ac.getBean(DiscountPolicy.class);
        assertThrows(NoUniqueBeanDefinitionException.class,
                () -> ac.getBean(DiscountPolicy.class));
    }

    @Configuration
    static class TestConfig {
        @Bean
        public DiscountPolicy rateDiscountPolicy() {
            return new RateDiscountPolicy();
        }

        @Bean
        public DiscountPolicy FixDiscountPolicy() {
            return new FixDiscountPolicy();
        }
    }

"부모 타입으로 조회 시, 자식이 둘 이상 있으면 중복 오류가 발생합니다"에 관한 테스트 코드입니다.

위에처럼 중복 예외이기에 NoUniqueBeanDefinitionException을 사용했고, 그러기에 Assertions에서 assertThrows를 사용했습니다.

(검증 단계 지우고 주석처리 되어있는 부분 활성화 하면 실제로 NoUniqueBeanDefinitionException이라는 오류가 뜹니다.)

 

테스트를 진행해보겠습니다.

부모 타입으로 조회 시, 자식이 둘 이상 있으면 중복 오류가 발생

NoUniqueBeanDefinitionException 예외가 터져야 테스트가 성공하는 로직인데, 역시나 성공했습니다.

 

이걸 해결하기 위해 빈 이름을 지정해보는 테스트 코드를 만들어보겠습니다.

@Test
    @DisplayName("부모 타입으로 조회 시, 자식이 둘 이상 있으면 빈 이름을 지정하면 됩니다.")
    void findBeanByParentTypeBeanName() {
        DiscountPolicy rateDiscountPolicy = ac.getBean("rateDiscountPolicy", DiscountPolicy.class);
        assertThat(rateDiscountPolicy).isInstanceOf(RateDiscountPolicy.class);
    }

빈 이름을 지정하기 때문에 바로 검증단계를 해도 오류가 나지 않습니다. (주석 따윈 없따)

부모 타입으로 조회 시, 자식이 둘 이상 있으면 빈 이름을 지정

역시 테스트가 성공적으로 작동된다는 것을 알 수 있습니다.

 

빈 이름 지정 말고도 부모 타입으로 조회 시, 자식이 둘 이상 있으면 중복 오류가 발생하는 것의 해결점은 또 있습니다.

특정 하위 타입으로 조회하는 것인데요. 근데, 이 방법은 좋지 않습니다. 왠지는 구현과 역할... 생각하면 되겠죠?

@Test
    @DisplayName("특정 하위 타입으로 조회")
    void findBeanBySubType() {
        RateDiscountPolicy bean = ac.getBean(RateDiscountPolicy.class);
        assertThat(bean).isInstanceOf(RateDiscountPolicy.class);
    }

특정 하위 타입으로 조회하는 것이기 때문에 단순하게 하나만 있겠죠?

 

테스트를 실행해보겠습니다.

특정 하위 타입으로 조회

테스트가 성공했습니다.

어차피 RateDiscountPolicy는 TestConfig에서 하나밖에 없기 때문에 오류가 뜨지 않고 결과가 하나로 잘 나옵니다.

 

이번에는 부모 타입으로 모두 조회하는 테스트 코드를 작성해보겠습니다.

@Test
    @DisplayName("부모 타입으로 모두 조회")
    void findAllBeanByParentType() {
        Map<String, DiscountPolicy> beansOfType = ac.getBeansOfType(DiscountPolicy.class);
        assertThat(beansOfType.size()).isEqualTo(2);
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key + " value = " + beansOfType.get(key)); 
        }
    }

특정 타입(부모 타입)을 모두 조회하는 것이기 때문에 beansOfType을 사용했습니다.

그리고, 스프링에서 getBeansOfType() 함수의 Return형을 Map으로 구현해놨기 때문에 Map 함수가 사용되었습니다.

또, for (String key : beansOfType.keySet()) 여기는 beansOfType 변수가 Map<String, DiscountPolicy>라는 타입이었는데, 여기서 keySet()을 하면 <String, DiscountPolicy>에서의 앞 데이터인 String 데이터들만 가져올 수 있습니다.

 

더 쉽게 설명해보겠습니다.

(사실 3-2에 있는 beansOfType의 Map 함수와 다를게 없습니다.)

beansOfType이라는 변수는 위의 사진과 같이 2개의 값이 있습니다.

각각의 하나 값이 String, DiscountPolicy 형의 데이터 2개를 갖고 있는 것입니다.

.keySet을 하면 앞쪽에 있는 key 값들로만 해서 배열을 만들어줍니다.

그러면 for문을 통해 빈 이름을 하나하나 출력해줄 수 있습니다.

그리고, .size는 사진처럼 Map의 데이터가 몇 개가 있나 확인하는 것입니다.

FixDiscountPolicy와 RateDiscountPolicy 2개가 나와야 하기에,

2개가 맞게 나오는지 Assertions의 assertThat으로 확인해주는 것입니다,

 

본론으로 들어가서..

참고로 테스트 코드에서 출력문은 실무에서 사용 안 합니다.

공부용이니까 보기 쉽게 하기 위해서 사용하는 것이에요.

 

테스트를 실행해보겠습니다.

부모 타입으로 모두 조회

출력문 적은 데로 결과가 아주 잘 나옵니다.

 

마지막으로, 아까처럼 부모 타입으로 모두 조회할건데, Object 타입으로 꺼내는 것을 해보겠습니다.

@Test
    @DisplayName("부모 타입으로 모두 조회 - Object")
    void findAllBeanByObjectType() {
        Map<String, Object> beansOfType = ac.getBeansOfType(Object.class);
        for (String key : beansOfType.keySet()) {
            System.out.println("key = " + key + " value = " + beansOfType.get(key));
        }
    }

최상위 객체인 Object으로 조회해보았습니다.

위에랑 비슷한 경우이기 때문에, beansOfType을 사용했구요. 그렇기에 Map 타입을 사용했습니다.

 

바로 테스트를 실행해보겠습니다.

부모 타입으로 모두 조회 - Object 조회

이야.... 엄청 많이 출력되었습니다.

지금 결과를 보면 뭔가 스프링이 내부적으로 사용하는 빈들까지 다 출력되었습니다.

스프링 안에는 여러 빈들이 등록되어있는데 얘네들까지 다 출력된 것입니다.

왜냐하면, 자바 객체는 모든 것이 Object 타입이기 때문입니다.

---

4. BeanFactory와 ApplicationContext

beanFactory와 ApplicationContext에 대해서 알아보도록 하겠습니다.

상속 관계

4-1. BeanFactory

• 스프링 컨테이너의 최상위 인터페이스입니다.
• 스프링 빈을 관리하고 조회하는 역할을 담당합니다.
• getBean()을 제공합니다.
• 지금까지 우리가 사용했던 대부분의 기능은 BeanFactory가 제공하는 기능입니다.

 

4-2. ApplicationContext

• BeanFactory 기능을 모두 상속받아 제공합니다.
• 빈을 관리하고 검색하는 기능을 BeanFactory가 제공해주는데, 그러면 둘의 차이가 뭘까요?
• 애플리케이션을 개발할 때는 빈을 관리하고 조회하는 기능은 몰론이고 수 많은 부가 기능이 필요합니다.

 

<ApplicationContext가 제공하는 부가 기능>

• 인터페이스 분리 원칙 기억!! 인터페이스는 다양하게 분리되어 있습니다.
• 메시지 소스를 활용한 국제화 기능
  • ex) 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력합니다. (국제화 기능 - 파일을 여러 개로 분리해 놓음)
• 환경 변수
  • 로컬, 개발, 운영 등을 구분해서 처리합니다.
• 애플리케이션 이벤트
  • 이벤트를 발행하고 구독하는 모델을 편리하게 지원합니다.
• 편리한 리소스 조회
  • 파일, 클래스 패스, 외부 등에서 리소스를 편리하게 조회합니다.

<정리✏️>

- ApplicationContext는 BeanFactory의 기능을 상속받습니다.
- ApplicationContext는 빈 관리 기능 + 편리한 부가 기능을 제공합니다.
- BeanFactory를 직접 사용할 일은 거의 없습니다✔️. 부가 기능이 포함된 ApplicationContext를 사용합니다.
- BeanFactory나 ApplicationContext를 스프링 컨테이너라고 합니다.

---

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

깊이는 이해 안 해도 되고, 그냥 이런게 있구나.. 정도로만 알아두면 됩니다.

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

자바 코드, XML, Groovy 등등 말이죠.

BeanFactory 인터페이스 밑에 ApplicationContext 인터페이스가 있습니다.

또, ApplicationContext 인터페이스 밑에는 AnnotationConfigApplicationContext, GenericXmlApplicationContext 등이 있습니다.

AnnotationConfigApplicationContext는 애노테이션 설정 정보를 사용하는 ApplicationContext를 뜻하며, AppConfig.class를 사용합니다.

GenericXmlApplicationContext는 자바 코드가 아닌 XML이라는 문서를 설정 정보로 사용하는 ApplicationContext를 뜻하며, appConfig.xml을 사용합니다.

그리고, 임의로 구현해서 만들 수도 있습니다. (XxxApplicationContext -> appConfig.xxx)

 

요즘 주로 많이 사용하는 것은 자바 코드를 기반으로 하는 AnnotationConfigApplicationContext이고, 과거에 많이 사용했던 것은 XML을 기반으로 했던 GenericXmlApplicationContext입니다.

XML을 기반으로 하는 GenericXmlApplicationContext가 옛날에 많이 사용했던 것이라 해도 이게 어떻게 돌아가는구나.. 정도는 알아야 합니다.

 

5-1. 애노테이션 기반 자바 코드 설정 사용

지금까지 했던 것입니다.

그리고, new를 해서 AnnotationConfigApplicationContext를 만들면서, AppConfig.class라는 설정 정보를 넣어줬습니다.

=> new AnnotationConfigApplicationContext(AppConfig.class)

즉, AnnotationConfigApplicationContext 클래스를 사용하면서 자바 코드로 된 설정 정보를 넘기면 된다는 뜻입니다.

 

5-2. XML 설정 사용

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

그러나, 아직 많은 레거시 프로젝트들이 XML로 되어 있고, 또 XML을 사용하면 컴파일 없이 빈 설정 정보를 변경할 수 있는 장점도 있으므로 한 번쯤 배워보는 것도 괜찮은 것 같습니다.

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

 

한 번 테스트 코드를 작성해보도록 하겠습니다.

test 패키지의 hello.core에 xml이란 패키지를 우선 만들어보겠습니다.

그리고, 이 패키지 안에 XmlAppContext 라는 자바 클래스를 만들어보겠습니다.

public class XmlAppContext {
    
    @Test
    void xmlAppContext() {
        ApplicationContext ac = new GenericXmlApplicationContext("appConfig.xml");
        MemberService memberService = ac.getBean("memberService", MemberService.class);
        assertThat(memberService).isInstanceOf(MemberService.class);
    }
}

우선 test 클래스부터 만들었습니다.

위에서 했던 거랑 비슷한데 GenericXmlApplicationContext를 사용했다는 점이 다르네요.

 

이대로 테스트를 돌리면 오류가 떠서 AppConfig를 만들어야 합니다.

test 패키지가 아닌 src 패키지의 main 패키지의 resources 패키지 안에 (XML 구성 파일->Spring 구성 선택)해서 appConfig.xml이란 스프링 구성 파일을 만듭니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

만들면 이렇게 있는데요. 여기 밑에다가 마저 작성해보겠습니다.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

	//여기서부터 추가한 부분
    <bean id="memberService" class="hello.core.member.MemberServiceImpl" >
        <constructor-arg name="memberRepository" ref="memberRepository" />
    </bean>

    <bean id="memberRepository" class="hello.core.member.MemoryMemberRepository"/>
</beans>

회원쪽(memberService와 memberRepository) 빈을 추가했습니다.

class는 경로를 다 적어야 합니다.

 

주문쪽 빈을 추가해보겠습니다.

<bean id="orderService" class="hello.core.order.OrderServiceImpl" >
        <constructor-arg name="memberRepository" ref="memberRepository"/>
        <constructor-arg name="discountPolicy" ref="discountPolicy" />
    </bean>

    <bean id="discountPolicy" class="hello.core.discount.RateDiscountPolicy" />

이렇게 코드를 다 짜놓으면 test에서 GenericXmlApplicationContext가 appConfig.xml에 추가한 내용을 끌어다가 동작하게 됩니다.

 

테스트를 실행해보겠습니다.

테스트 성공했습니다.

<정리✏️>

- xml 기반의 appConfig.xml 스프링 설정 정보와 자바 코드로 된 AppConfig.java 설정 정보를 비교해보면 거의 비슷하다는 것을 알 수 있습니다.
- xml 기반으로 설정하는 것은 최근에 잘 사용하지 않으므로 이 정도로 마무리 하고, 필요하면 스프링 공식 레퍼런스 문서를 확인해보면 됩니다.
https://spring.io/projects/spring-framework

---

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

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

그 중심에는 BeanDefinition이라는 추상화가 있기 때문입니다.

 

쉽게 얘기해서 역할과 구현을 개념적으로 나눈 것입니다.

XML을 읽어서 BeanDefinition을 만들면 되고, 자바 코드를 읽어서 BeanDefinition을 만들면 됩니다.

그리고, 스프링 컨테이너 입장에서는 자바 코드인지, XML인지 몰라도 됩니다. 오직 BeanDefinition만 알면 됩니다.

이것을 기반으로 빈을 생성하는 것입니다.

 

이 BeanDefinition을 빈 설정 메타 정보라고 합니다.

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

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

스프링 컨테이너 자체는 BeanDefinition에만 의존합니다.

얘가 class로 설정된 정보인지, xml로 설정된 정보인지, 임의로 설정된 정보인지 상관을 하지 않는 것입니다.

결국 보면 BeanDefinition 자체가 인터페이스입니다.

 

코드 레벨로 조금 더 깊이 있게 들어가보겠습니다.

이거 그림은 걍 깊이 있게 알면 좋은거고, 몰라도 됩니다.

몰라도 스프링 개발하는 데에 전혀 지장 없습니다.

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

GenericXmlApplicationContext는 XmlBeanDefinitionReader를 사용해서 appConfig.xml 설정 정보를 읽고, BeanDefinition을 생성합니다.

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

 

6-1. BeanDefinition 살펴보기

<BeanDefinition 정보⭐>

- BeanClassName: 생성할 빈의 클래스 명 (자바 설정처럼 factory 역할의 빈을 사용하면 없음)
- factoryBeanName: factory 역할의 빈을 사용할 경우의 이름 (ex - appConfig)
- factoryMethodName: 빈을 생성할 factory 메서드 지정 (ex - memberService)
- Scope: 싱글톤 (기본값)
- lazyInit: 스프링 컨테이너를 생성할 때, 빈을 생성하는 것이 아닌 실제 빈을 사용할 때까지 최대한 생성을 지연처리 하는지의 여부
- InitMethodName: 빈을 생성하고, 의존 관계를 적용한 뒤에 호출되는 초기화 메서드 이름
- DestoryMethodName: 빈의 생명 주기가 끝나서 제거하기 직전에 호출되는 메서드 이름
- Constructor arguments, Properties: 의존 관계 주입에서 사용 (자바 설정처럼 factory 역할의 빈을 사용하면 없음)

이게 근데 말로만 보면 이해가 잘 안 갈 수 있습니다.

그래서, 코드로 한 번 더 봐보도록 하겠습니다.

 

test 패키지의 hello.core에서 beandefinition이라는 패키지를 만들어보겠습니다.

그리고, 이 패키지 안에 BeanDefinitionTest라는 자바 클래스를 만들어보겠습니다.

빈 설정 메타정보를 확인하는 테스트 입니다.

public class BeanDefinitionTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);
    
    @Test
    @DisplayName("빈 설정 메타정보 확인")
    void findApplicationBean() {
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);

            if (beanDefinition.getRole() == BeanDefinition.ROLE_APPLICATION) {
                System.out.println("beanDefinitionName = " + beanDefinitionName +
                        " beanDefinition = " + beanDefinition);
            }
        }
    }
}

 

테스트를 실행해보겠습니다.

빈 설정 메타정보 확인

이 결과에서 memberService와 memberRepository를 봐보도록 하겠습니다.

속성을 쫙 봐보면 scope라는 게 있는데 여기선 할당이 되어있지 않네요. (할당이 되어있지 않으면 싱글톤이라고 합니다.)

abstract는 추상, lazyInit은 스프링 빈을 실제 사용할 시점에 초기화하라는 정보입니다.

이 외에도 다양한 정보가 있으면 위에 있는 정보들 참고하면 됩니다.

그냥 지금은 이런 종류의 메타 정보가 있다 정도로 알아두면 되고, 이런 메타 정보를 기반으로 실제 인스턴스를 생성할 수 있다는 것을 알아두면 됩니다.

<정리✏️>

- BeanDefinition을 직접 생성해서 스프링 컨테이너에 등록할 수도 있습니다.
=> 하지만, 실무에서 BeanDefinition을 직접 정의하거나 사용할 일은 거의 없습니다.
- BeanDefinition에 대해서는 너무 깊이 이해하기 보다는 스프링이 다양한 형태의 설정 정보를 BeanDefinition으로 추상화해서 사용하는 것 정도만 이해하면 됩니다.
- 가끔 스프링 코드나 스프링 관련 오픈 소스의 코드를 볼 때, BeanDefinition이라는 것이 보일 때가 있습니다.
  이 때, 이런 메커니즘을 떠올리면 됩니다.

---

오늘 공부도 이렇게 끝이 났습니다.

다음에는 싱글톤에 관해서 공부할 예정입니다.

그럼 안뇽!