@Configuration 및 @Bean vs @ComponentScan

2024. 5. 14. 17:06Back-End/Spring

스프링 프레임워크에서는 빈(Bean)을 등록하는 여러 가지 방법이 있습니다. 그 중에서도 @Configuration 및 @Bean 애노테이션을 사용하는 방법과 @ComponentScan을 사용하는 방법에 대해 알아보겠습니다. 이 글에서는 이 두 가지 방법의 차이점과 각각의 특징을 살펴보겠습니다.

 

@Configuration과 @Bean

@Configuration 애노테이션은 스프링에서 설정 클래스를 정의할 때 사용됩니다. 설정 클래스는 일반적으로 빈의 구성을 정의하는 데 사용됩니다. @Bean 애노테이션은 이러한 설정 클래스 내에서 메서드에 적용되어 해당 메서드가 반환하는 객체를 스프링 애플리케이션 컨텍스트에 빈으로 등록합니다.

 

AppConfig.java

@Configuration
public class AppConfig {
    
    @Bean
    public UserService userService() {
        return new UserServiceImpl();
    }
    
    @Bean
    public UserController userController() {
        return new UserController(userService());
    }
}

위 코드에서 AppConfig 클래스는 설정 클래스로서 @Configuration 애노테이션이 붙어 있습니다. 이 클래스 내부에는 @Bean 애노테이션을 사용하여 userService()와 userController() 메서드를 정의하고 각각의 빈을 생성합니다.

 

@ComponentScan

@ComponentScan 애노테이션은 스프링에서 자동으로 빈을 찾아 등록하는 데 사용됩니다. 이 애노테이션은 주로 패키지를 스캔하고 그 안에 있는 모든 컴포넌트를 검색하여 빈으로 등록합니다. 이 때 컴포넌트는 @Component, @Controller, @Service, @Repository 등의 애노테이션으로 표시된 클래스입니다.

아래는 간단한 예시 코드입니다.

 

AppConfig.java

@Configuration
@ComponentScan(basePackages = "com.example")
public class AppConfig {
    // 이 클래스는 빈 설정에 대한 추가적인 내용을 포함할 수 있습니다.
}

위 코드에서 @ComponentScan 애노테이션은 com.example 패키지 및 하위 패키지를 스캔하여 모든 @Component 애노테이션이 붙은 클래스를 검색하고 빈으로 등록합니다.

 

두 방법의 차이점

  • @Configuration 및 @Bean을 사용하는 방법은 빈의 생성과 의존성을 명시적으로 정의할 수 있습니다. 반면에 @ComponentScan은 자동으로 빈을 검색하고 등록하므로 보다 간편합니다.
  • @Configuration 및 @Bean을 사용하는 방법은 설정 클래스에서 모든 빈을 직접 관리하기 때문에 빈의 생성 과정을 더 세밀하게 제어할 수 있습니다. 반면에 @ComponentScan은 자동으로 빈을 검색하므로 설정에 대한 관리 부담이 덜합니다.
  • @Configuration 및 @Bean을 사용하는 방법은 다른 빈 설정을 함께 포함할 수 있습니다. 반면에 @ComponentScan은 패키지 스캔만으로 빈을 검색하기 때문에 다른 설정과 조합하여 사용하기 어려울 수 있습니다.

결론

@Configuration @Bean 사용하는 방법과 @ComponentScan 사용하는 방법은 각각의 장단점을 가지고 있습니다. 개발자는 자신의 프로젝트의 요구 사항과 환경에 맞게 적절한 방법을 선택하여 사용해야 합니다.

'Back-End > Spring' 카테고리의 다른 글

ResultSetExtractor  (0) 2024.05.17
@Transactional과 TransactionTemplate  (0) 2024.05.17
배치 업데이트(Batch Update)  (0) 2024.05.17
Spring Data JDBC  (0) 2024.05.16
IoC와 DI  (0) 2024.05.14