- 해당 게시물은 인프런 "스프링 핵심 원리 - 기본편" 강의를 참고하여 작성한 글 입니다.

스프링 핵심 원리 - 기본편

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

ApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

• ApplicationContext는 스프링 컨테이너다.
• ApplicationContext 는 인터페이스인데, 그것을 구현한 클래스가AnnotationConfigApplicationContext다.
• 스프링 컨테이너를 생성하는 방법에는 XML 기반과 애노테이션 기반이 있다.
• 우리가 AppConfig.class 에 @Configuration 애노테이션을 달고, 메서드에 @Bean을 달았는데. 이 방법이 애노테이션 기반 자바 설정 클래스로 스프링 컨테이너를 생성한 것이다.

1) 스프링 컨테이너 생성

• 스프링 컨테이너를 생성 할 때 구성 정보(설정 정보)를 정해줘야 한다.
• 여기서는 AppConfig.class 를 구성 정보로 지정했다.

2) 스프링 빈 등록

• 스프링 컨테이너는 파라미터로 넘어온 설정 클래스 정보를 사용해서 @Bean이 붙은 메서드의 반환 객체를 모두 스프링 빈으로 등록한다.
• { @Bean 이름 - @Bean 객체 } 쌍으로 컨테이너에 저장된다.
• 빈 이름은 디폴트로 메서드 이름과 똑같이 정해지는데 직접 이름을 지을 수도 있다.

주의: 빈 이름은 항상 다른 이름을 부여해야 한다. 같은 이름을 부여하면, 다른 빈이 무시되거나, 기존 빈을덮어버리거나 설정에 따라 오류가 발생한다

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

• 애노테이션 기반 자바 설정 클래스(AppConfig.class)를 기반으로 스프링 컨테이너를 생성한다.
• @Bean 을 달아놓은 메서드를 전부 호출하여 메서드 명 그대로 이름붙여서 컨테이너에 스프링 Bean으로 등록한다.

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

• 스프링 컨테이너가 설정 정보를 참고해서 의존관계를 주입(DI) 한다.
• 어떤 인터페이스에 어떤 구현체를 생성해서 인스턴스 레퍼런스를 넘길지 정보를 보고 의존관계를 주입한다.
• 단순히 자바 코드를 호출하는 것 같아보이지만, 차이가 있다. 이 차이는 뒤에서 싱글톤 컨테이너에서 설명한다.

[ 참고 ]

• 스프링 컨테이너는 빈을 생성하고 의존관계를 주입한다는 것이 핵심이다.
• 스프링 빈을 생성하고 의존관계를 주입하는 단계를 나눠서 그림으로 그렸다.
• 사실 스프링에서는 이것이 한 번에 처리되는 것이고 이해를 위해 나눠 그린 것이다.

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

테스트 코드를 작성해서 스프링 컨테이너에 스프링 빈이 등록되었는지 확인하자.

appConfig.class를 포함해서 @Bean 을 달아놓은 스프링빈이 출력되었다.
드래그한 윗 부분은 스프링이 내부적으로 스프링 자체를 확장하기 위해 필요한 스프링빈이다.

스프링 내부적으로 필요한 것 말고, 내가 정의한 스프링 빈만 출력하자.
getRole()== ROLE_APPLICATION : 개발을 위해 등록한 (일반적으로 사용자가 등록한) 빈만 출력된다.

파랗게 드래그한 부분을 보면 appConfig.class를 포함해서 내가 정의한 빈 4개가 출력된다.

3. 스프링 빈 조회 - 기본

1) getBean()

메서드로 빈 이름을 넘기면 스프링 빈을 조회할 수 있다.

2) 이름 없이 타입으로만 조회할 수 있다.

memberService 빈 이름을 호출하지 않고, memberService.class 타입으로 빈을 조회할 수 있다.

3) 구체 타입 으로 조회할 수 있다.

memberService 빈을 호출하면 구체클래스 memberServiceImpl을 반환해준다.
AppConfig.class 코드를 열어 보면 memberService 스프링 빈의 반환 타입을 확인할 수 있다.

따라서 스프링 빈을 memberServiceImpl 구체 타입으로 조회 가능하다.

좋은 코드는 아니다. 프로그래머는 "추상화에 의존해야지, 구현체에 의존하면 안된다." 는 SOLID원칙을 다시 떠올리자

4) 존재하지 않는 빈을 조회해보자.

테스트 작성 시, 항상 실패 케이스도 만들어야 한다. XXX 라는 이름의 빈을 조회하면,
"NoSuchBeanDefinitionException: No bean named 'XXX' available" 라는 오류가 발생해야한다.

잘 발생하는 모습이다.

5) 실패 케이스 "@@예외가 터지면 성공이다."라는 테스트를 작성하자.

람다식을 사용해서 테스트를 작성할 수 있다.