테크커런트

스프링에서 수동으로 빈을 등록 할때 @Configuration 클래스 안에 @Bean을 사용한다. 왜 그런지 살펴보자.

● @Configuration 안에 @Bean을 사용하는 이유, proxyBeanMethods

 - @Bean 어노테이션을 이용한 수동 빈 등록

스프링에선 일반적으로 컴포넌트 스캔을 이용해 자동으로 빈을 등록하는 방법을 이용한다. 하지만 @Bean 어노테이션을 사용해 수동으로 빈을 등록해야 할 때도 있다.

• 개발자가 직접 제어가 불가능한 라이브러리를 활용할 때
• 애플리케이션 전 범위적으로 사용되는 클래스를 등록할 때
• 다형성을 활용하여 여러 구현체를 등록해야 할 때

 @Bean을 이용한 수동 빈 메소드는 스프링 빈 안에만 구현되어 있다면 모두 동작한다. 하지만 스프링은 @Bean은 반드시 @Configuration 어노테이션 활용하도록 하는데, 그 이유는 @Configuration에 특별한 부가 기능이 적용되기 때문이다.

●  @Configuration 에 적용되는 프록시 패턴

- @Configuration 어노테이션 안에는 @Component 어노테이션이 붙어 있어 @Configuration이 붙어있는 클래스 역시 스프링 빈으로 등록이 된다. 그럼에도 스프링이 @Configuration을 만든 이유는 CGLib으로 프록시 패턴을 적용해 수동으로 등록하는 스프링 빈이 반드시 싱글톤으로 생성됨을 보장하기 위해서다.

public class Resource {}

위 클래스를 @Component를 이용해 자동으로 빈 등록을 한다면 스프링이 해당 크래스의 객체의 생성을 제어하게 되고(제어의 역전, IoC) 하나의 객체만 생성되도록 컨트롤 할 수 있다. 하지만 위의 클래스를 @Bean을 이용해 직접 빈으로 등록해준다고 하면, 우리는 다음과 같이 해당 빈 등록 메소드를 여러 번 호출할 수 있게 된다.

@Configuration
public class MyBeanConfiguration { 

    @Bean 
    public Resource resource() {
        return new Resource(); 
    } 
    
    @Bean 
    public MyFirstBean myFirstBean() { 
        return new MyFirstBean(resource()); 
    } 
    
    @Bean 
    public MySecondBean mySecondBean() { 
        return new MySecondBean(resource()); 
    } 
}

 실수로 위와 같이 빈을 생성하는 메소드를 여러 번 호출 했다면 불필요하게 여러 개의 빈이 생성이 된다. 스프링은 이러한 문제를 방지하고자 @Configuration이 있는 클래스를 객체로 생성할 때 CGLib을 사용해 프록시 패턴을 적용한다. 그래서 @Bean이 있는 메소드를 여러 번 호출하여도 항상 동일한 객체를 반환하여 싱글톤을 보장한다.

@Configuration
public class MyBeanConfigurationProxy extends MyBeanConfiguration {

    private Object source;

    @Override
    public Resource resource() {
        if (resource == null) {
            source = super.resource();
        }
        return source;
    }

    @Override
    public MyFirstBean myFirstBean() {
        return super.myFirstBean();
    }

    @Override
    public MySecondBean mySecondBean() {
        return super.mySecondBean();
    }
}

 CGLib은 상속을 통해 프록시를 구현하므로 위와 같이 프록시가 구현 됬다고 이해 할 수 있다. 물론 이렇게 생성이 되는건 아니라 내부 클래스를 사용하는 등의 차이가 있으므로 이해를 돕기 위한 코드로 보면 된다.

●  싱글톤 여부를 제어하기 위한 proxyBeanMethods

 대부분 @Bean에 의한 수동 빈 등록을 할 때 싱글톤으로 생성되기를 원한다. 하지만 @Bean 메소드를 호출할 때 의도적으로 매번 다른 객체가 생성되기를 바랄 수 있다. 그럴 경우엔 @Configuration 어노테이션이 갖고 있는 proxyBeanMethods를 false로 주면 된다.

@Configuration(proxyBeanMethods = false)
public class MyBeanConfigurationProxy extends MyBeanConfiguration {

    private Object source;

    @Override
    public Resource resource() {
        if (resource == null) {
            source = super.resource();
        }
        return source;
    }

    @Override
    public MyFirstBean myFirstBean() {
        return super.myFirstBean();
    }

    @Override
    public MySecondBean mySecondBean() {
        return super.mySecondBean();
    }
}

https://mangkyu.tistory.com/234

● IoC(Inversion of Control)란?

- IoC는 제어의 역전이라는 뜻으로 프로그램의 제어의 흐름을 직접 제어하는 것이 아니라 외부에서 관리하는 것을 말한다. 이전에는 개발자가 객체를 생성하고 관리하며 프로그램의 제어 흐름을 스스로 조종했다. 하지만 Spring을 이용하면 스프링 컨테이너가 프로그램의 제어흐름을 제어하게 된다.

● 스프링 컨테이너(Spring Container)란?

 - 스프링 컨테이너는 스피링의 빈(Bean)을 생성하고 관리한다. 스프링 컨테이너는 IoC Container 혹은 DI Container라고 불리는데, 이는 스프링 컨테이너가 IoC 혹은 DI를 도맡아 진행하기 때문이다. 즉, 스프링 컨테이너는 스프링 Bean들을 생성하고, 이들의 의존 관계를 연결해 주는 역할을 한다.

 이러한 스프링 컨테이너는 BeanFctory와 Application Context로 나뉘는데 둘의 내용은 다음과 같다.

● BeanFactory

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

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

● ApplicationContext

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

 - 다음과 같은 부가기능들을 제공한다.

• 메시지 소스를 활용한 국제화 기능
• 환경변수 - 로컬, 개발, 운영 등을 구분해서 처리
• 애플리케이션 이벤트 관리
• 편리한 리소스 조회

보통 스프링 컨테이너라 하면 ApplicationContext를 뜻한다. BeanFactory의 모든 기능을 상속 받는데다 편리한 부가기능을 제공하기 때문에 BeanFactory 보다는 ApplicationContext를 사용한다.

● 스프링 빈(Bean)이란?

스프링 공식문서에서 확인해 보자면

 스프링에서는, 스프링 IoC컨테이너에 의해 관리되고 애플리케이션의 핵심을 이루는 객체들을 Bean이로고 부른다. Bean은 스프링 IoC 컨테이너에 의해 인스턴스화되어 조립되거나 관리되는 객체를 말한다.

즉, 스프링 빈은 스프링 컨테이너에 의해 만들어지고 관리되는 객체라는 뜻이다.

[Spring] IoC,DI, 스프링 컨테이너(Container), 스프링 빈(Bean)이란? (tistory.com)