모각소-4(스프링 빈, 스프링 컨테이너)

LEEHYUNJE·2024년 1월 20일
모각소
0

아주대학교_모각소!

목록 보기
5/23
post-thumbnail

오늘은 온전히 java로 만든 코드를 spring을 사용해서 전환하는 과정을 공부했다.
김영한 강사님의 spring강의 내용인데 너무 어렵지만 꾸역꾸역 이해하며 듣는 중이다.

스프링으로 전환하기

https://github.com/LEEHUYNJE/-_Spring_-
링크에 만들어진 java 코드에 스프링을 사용하여 코드를 전환해 보도록 하자.

스프링 컨테이너

  • ApplicationContext를 스프링 컨테이너 라고한다.
  • 기존에는 AppConfig를 사용해서 직접 객체를 생성하고 DI를 했지만, 이제부터는 스프링 컨테이너를 통해서 사용한다.
  • @Configuration이 붙은 AppConfig를 설정 정보로 사용한다. 이때 @Bean이라 적힌 메서드를 모두 호출해서 반환된 객체를 스프링 컨테이너에 등록한다. 이렇게 컨테이너에 등록된 객체를 스프링 빈이라고 한다.
  • 스프링 빈은 메서드의 명을 스프링 빈의 이름으로 사용한다.
  • @Bean(name="이름")을 하면 이름을 변경할 수 있지만 관례상 선호하지는 않는다.
  • applicationContext.getBean()를 통해서 스프링 빈을 찾을 수 있다.

Q1. 아니 더 어려워진 것 같은데 굳이 써야하나? 무슨 장점이 있을까?

  • 어마어마한 장점이 있다.
    -> 뭐가 더 나은지 이제 다 알아야함.

4. 스프링 컨테이너와 스프링 빈

스프링 컨테이너 생성

//스프링 컨테이너 생성
ApplicationContext applicationContext =
 new AnnotationConfigApplicationContext(AppConfig.class);
  • ApplicationContext를 스프링 컨테이너라고 한다.
  • ApplicationContext는 인터페이스이다.
  • XML 기반으로 만들 수 있고, 에노테이션 기반의 자바 설정 클래스로 만들 수 있음
    -> 요즘은 에노테이션 기반으로 만든다.

##참고: 스프링 컨테이너를 부를 때 BeanFactory, ApplicationContext로 구분해서 이야기한다.

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

  • new AnnotationConfigApplicationContext(AppConfig.class)
  • 스프링 컨테이너를 생성할 때는 구성 정보를 지정해 주어야한다.
  • 여기서는 AppConfig.Class를 구성정보로 지정

  • @Bean 붙은거를 다 호출해서 컨테이너에 넣어 놓는다.
  • 빈이름은 항상 다른 이름을 부여해야한다.

  • 스프링 빈들을 컨테이너에 넣은 모습

  • 동적인 객체 인스턴스를 주입(의존 관계 주입)
  • 단순히 자바 코드를 호출하는 것 같지만, 차이가 있다. 이 차이는 뒤에 싱글톤 컨테이너에서 설명

참고

  • 스프링은 빈을 생성하고, 의존 관계를 주입하는 단계가 나누어져 있다.
  • 자바 코드로 스프링 빈을 등록하면 생성자를 호출하면서 의존관계 주입도 한번에 처리된다.

정리
스프링 컨테이너를 생성, 설정 정보를 참고해서 스프링 빈도 등록하고, 의존관계도 설정했음

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

public class ApplicationContextInfoTest {

    AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(AppConfig.class);

    @Test
   @DisplayName("모든 빈출력하기")
    void findAllBean(){
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            Object bean = ac.getBean(beanDefinitionName);
            System.out.println("name = "+ beanDefinitionName + "object = "+ bean   );
        }

    }
    @Test
   @DisplayName("모든 빈출력하기")
    void findApplicationBean(){
        String[] beanDefinitionNames = ac.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = ac.getBeanDefinition(beanDefinitionName);

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

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

    }


}
  • 모든 빈 출력하기
    • 실행하면 스프링에 등록된 모든 빈 정보를 출력 할 수 있다.
    • ac.getBeanDefinitionNames() : 스프링에 등록된 모든 빈 이름을 조회한다.
  • 애플리케이션 빈 출력하기
    • 스프링이 내부에서 사용하는 빈은 제외, 내가 등록한 빈만 출력
    • getRole()로 내부에서 사용하는 빈을 구분할 수 있다.
      • ROLE_APPLICATION : 일반적으로 사용자가 정의한 빈
      • ROLE_INFRASTRUCTURE : 스프링이 내부에서 사용하는 빈

스프링 빈 조회 - 기본

  • ac.getBean(빈이름, 타입)
  • ac.getBean(타입)
  • 조회 대상 스프링 빈이 존재하지 않으면 예외가 발생한다.
    • NoSuchBeanDefinitionException: No bean named 'xxxxx' available
 @Test
    @DisplayName("구체 타입으로 조회")
    void findBeanByName2(){
        MemberService memberService = ac.getBean("memberService", MemberServiceImpl.class); //인스턴스 타입으로도 가능
        assertThat(memberService).isInstanceOf(MemberServiceImpl.class);
        //하지만 좋은 코드는 아님, 구체에 의존했기 때문

    }
  • 구체 타입으로 조회할 수 있다.
  • 하지만, 구체 타입으로 조회를 하게 된다면, MemberServiceImpl.class 구체가 다른 구체로 변경되었을 때 테스트 코드를 변경 시켜야하므로 좋지 않은 방법이다.
@Test
   @DisplayName("빈 이름으로 조회X")
   void  findBeanByNameX(){
      assertThrows(NoSuchBeanDefinitionException.class, () ->
               ac.getBean("xxxx", MemberService.class)); // ac.getBean을 했을때 익셉션이 터져야 테스트가 성공함
   }
  • assertThrows(NoSuchBeanDefinitionException.class, () ->ac.getBean("xxxx", MemberService.class));
    • java의 람다식으로, getBean()에서 NoSuchBeanDefinitionException이 발생하면 테스트가 성공한다.

    스프링 빈 조회 - 동일한 타입이 둘이상

  • 타입으로 조회시 같은 타입의 스프링 빈이 둘 이상이면 오류가 발생한다. 이때는 빈 이름을 지정해야한다.
  • ac.getBeansOfType() 을 사용하면 해당 타입의 모든 빈을 조회할 수 있다.
 @Test
    @DisplayName("타입으로 조회시 같은 타입이 둘 이상 있으면, 빈 이름을 지정하면 된다")
    void findBeanByName(){
        MemberRepository memberRepository = ac.getBean("memberRepository1",MemberRepository.class);
        assertThat(memberRepository).isInstanceOf(MemberRepository.class);
    }
  • 같은 타입의 bean이 복수라면, 이름도 넣어 지정해주면 오류가 나지 않는다.

스프링 빈 조회 - 상속관계

  • 부모 타입으로 조회하면, 자식 타입도 함께 조회한다. - > 중요
  • 그래서 모든 자바 객체의 최고 부모인 Object 타입으로 조회하면 모든 스프링 빈을 조회한다.


위 그림은 상속관계를 표현한 것이고, 왼쪽은 조회했을때 같이 조회되는 항목들을 간단하게 정리한 것

  @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));
        }

    }
  • DiscountPolicy.class 만 조회를 한 모습

  • 하지만 테스트 실행 결과, DiscountPolicy를 구현한 객체들 까지 모두 Mapping 이 되어 있는 모습니다.

BeanFactory와 ApplicationContext


빈펙토리

  • 스프링 컨테이너의 최상위 인터페이스
  • 스프링 빈을 관리하고 조회하는 역할. getBean()

ApplicationContext

  • 빈 펙토리 기능을 모두 상속받아서 제공한다.
  • 애플리케이션을 개발할 때는 빈을 관리하는 것 뿐만 아니라, 수 많은 부가기능이 필요하다.

  • 메시지소스를 활용한 국제화 기능

    • 예를 들어서 한국에서 들어오면 한국어로, 영어권에서 들어오면 영어로 출력

  • 환경변수

    • 로컬, 개발, 운영등을 구분해서 처리

  • 애플리케이션 이벤트

    • 이벤트를 발행하고 구독하는 모델을 편리하게 지원

  • 편리한 리소스 조회

    • 파일, 클래스패스, 외부 등에서 리소스를 편리하게 조회

    정리

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

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

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

  • ApplicationContext를 사용한다.

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

XML

  • 레거시 코드나 가끔 볼 수 있는 정도로 현대 사용되지만, 백엔드를 한다면 한번쯤은 배워볼만 하다

그러므로 정리는 간단하게만 할 것임

##java 코드가 아닌 것은 resources 파일에 만드는 것이다.

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

  • 스프링은 BeanDefinition 이라는 추상화가 존재한다
  • 즉 역할과 구현을 개념적으로 나눴다.
    • 스프링 컨테이너는 자바 코드인지, XML인지 몰라도 오직 BeanDefinition 만 알면된다.

  • 잘몰라도 상관없으니 교양이다 하고 들어라

  • AnnotationConfigApplicationContext 는 AnnotatedBeanDefinitionReader 를 사용해서
    AppConfig.class 를 읽고 BeanDefinition 을 생성한다.
  • GenericXmlApplicationContext 는 XmlBeanDefinitionReader 를 사용해서 appConfig.xml
    설정 정보를 읽고 BeanDefinition 을 생성한다.
  • 새로운 형식의 설정 정보가 추가되면, XxxBeanDefinitionReader를 만들어서 BeanDefinition 을 생성하면 된다.

BeanDefinition 정보

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

정리

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

모각소 소감

정말 세상에는 쉬운게 없다는 생각이 들게 만든 강의다. 1학년때 웹개발은 비전공자들도 쉽게 할 수 있는 영역이라고 들었기 때문에 웹개발은 쉽다고 생각했었는데, 그 어리석은 생각을 깨부신 내용같다. 빈, 컨테이너, 의존관계와 같은 개념들은 이해가 어느정도 됐는데, 이런 개념들을 밥먹듯이 쉽게 적용시키는 김영한 강사님의 개발 솜씨를 보고 벽을 느꼈다. 격의 차이를 느꼈고, 더 열심히 해야겠다라는 생각밖에 안들었다. 앞으로도 화이팅

출처

김영한 강사님 - 스프링 핵심 원리(기본편)
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

profile
LEEHYUNJE
현재진행중
이전 포스트

모각소 3(java의 메모리 구조)

다음 포스트

모각소-5(싱글톤 컨테이너)

0개의 댓글