스프링 코어(번외-2) - 스프링 빈의 자동 & 수동 등록

이번에는 스프링 빈의 자동 & 수동 등록에 대해서 다뤄보겠습니다.

 

이번 포스트 역시 번외입니다.

스프링 빈의 자동, 수동 등록을 어떻게 해야할까에 대한 내용을 다룰 것이고,

이 포스트야말로 정말 크게 중요하지 않을 수 있습니다.

 

그리고 자동, 수동 등록의 경우 

업무 수준에서는 어떻게 동작할 지 회사마다 기준이 있을 겁니다.

그렇기 때문에 가벼운 마음으로 읽어주시면 될 것 같습니다.

 

 

요즘 추세는 아무래도 자동 등록을 선호하고 사용하는 것이 트렌드인 것 같습니다.

사실 설정 정보를 바탕으로 명확히 나누는 것이 바람직하지만,

수동 등록의 경우 @Configuration, @Bean, 객체 생성 등의 코드를 일일이 다 적어줘야 합니다.

이 부분은 개발자의 입장에서는 굉장히 번거롭습니다.

그리고 수백개가 될 수도 있는 스프링 빈을 일일이 이렇게 등록하는 것은 너무 비효율적입니다.

또한 관리할 빈이 많아지기 때문에 유지보수하는 것도 굉장히 어려울 것입니다.

@Component만을 사용해서 스프링 빈 등록이 완료되는 것이 아무래도 훨씬 편하겠죠 ㅎㅎ

 

그래도 수동 등록의 경우 직접 등록하기 때문에 정확하게, 내 맘대로 등록할 수 있다는 장점은 있습니다.

그럼 수동 등록은 언제 사용하는 것이 괜찮을까요?

 

애플리케이션 내에서 한 번 스프링 빈으로 등록된 후 광범위하게 이용되는 객체가 그 예입니다.

• 예를 들어 공통 로그 처리를 하는 객체를 하나 만들었을 시
• 어떤 업무를 진행하든지 공통 로그 처리는 항상 진행됩니다.
• 그렇기 때문에 공통 로그 처리는 어디에서든지 작동하기 때문에 광범위하게 이용될 것입니다.
• 그리고 공통 로그 처리에 문제가 생긴 경우 수동 등록을 했다면 바로 찾아가서 해당 문제를 수정하면 될 것입니다.
• 공통 로그 처리를 하는 객체를 자동 등록했다면, 아마도 문제 수정을 하는데 있어 수동 등록보다 찾기가 어려워서 그만큼 시간이 더 걸릴 것 같습니다..

 

즉, 공통 업무를 처리하는 객체를 수동 등록하면 훨씬 더 유지보수에 좋을 것입니다.

 

 

그리고 이전 포스트에 적었던 조회한 빈이 모두 필요한 경우를 생각해 봅시다.

DiscountService는 빈 정보를 Map<String, DiscountPolicy>에 주입받는데, 이 코드는 사실 단번에 이해하기 쉬운 코드는 아닙니다.

RateDiscountPolicy, FixDiscountPolicy가 자동 등록이 되어있기 때문에 여러 코드를 확인하면서 코드 이해를 진행해야 합니다.
(DiscountPolicy가 Interface이고 나머지는 구현체여서 더 그렇겠죠?)

그러면 이런 경우에 수동 등록을 했을 경우 여러 코드를 확인하지 않아도 될 것입니다.

 

예시

@Configuration
public class DiscountPolicyConfig {

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

이런 식으로 Config 클래스를 만들었다면 

빈의 이름, 어떤 빈이 주입될지 파악이 훨씬 빠르기 때문에

수동 등록을 사용하는 것이 좀 더 효율적일 것이라고 생각됩니다.

 

 

 

 

자동 등록 & 수동 등록에 대해 좀 더 짧고 굵게 요약해보겠습니다.

1. 자동 등록이 대세 - 자동 등록 이용하기
2. 수동 등록 - 공통 업무를 처리하는 객체를 등록하기
3. 다형성(인터페이스-구현체)을 활용한 객체 - 수동 등록을 고민하기

이렇게 요약될 수 있을 것 같습니다.

 

 

 

 

번외로 간단하게 업무 수준에서의 자동등록 & 수동등록에 대해 알아봤습니다.

 

 

 

 

 

출처: 인프런 - 스프링 핵심원리(기본편) by 김영한