자동 , 수동 스프링 빈 등록의 올바른 실무 운영 기준

편리한 자동 기능을 기본으로 사용하자

• 그러면 어떤 경우에 컴포넌트 스캔과 자동 주입을 사용하고 , 어떤 경우에 설정 정보를 통해서 수동으로 빈을 등록하고 , 의존관계도 수동으로 주입해야 할까?
• 결론부터 이야기하면 , 스프링이 나오고 시간이 갈 수록 점점 자동을 선호하는 추세다.
• 스프링은 @Component뿐만 아니라 @Controller , @Service , @Repository처럼 계층에 맞추어 일반적인 애플리케이션 로직을 자동으로 스캔할 수 있도록 지원한다.
• 거기에 더해서 최근 스프링 부트는 컴포넌트 스캔을 기본으로 사용하고 , 스프링 부트의 다양한 스프링 빈들도 조건이 맞으면 자동으로 등록하도록 설계 했다.
• 그리고 결정적으로 자동 빈 등록을 사용해도 OCP , DIP를 지킬 수 있다.

그러면 수동 빈 등록은 언제 사용하면 좋을까?

• 애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있다.
• 업무 로직 빈
  • 웹을 지원하는 "Controller" , 핵심 비즈니스 로직이 있는 "Service" , 데이터 계층의 로직을 처리하는 "Repository"등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
• 기술 지원 빈
  • 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다.
• 업무 로직은 숫자도 매우 많고 , 한 번 개발해야 하면 Controller , Service , Repository 처럼 어느정도 유사한 패턴이 있다.
  • 이런 경우 자동 기능을 적극 사용하는 것이 좋다.
• 기술 지원 로직은 업무 로직과 비교해서 그 수가 매우 적고 , 보통 애플리케이션 전반에 걸쳐서 광범위하게 영향을 미친다.
  • 업무로직은 문제가 발생 했을 때 어디가 문제인지 명확하게 잘 들어나지만
  • 기술 지원 로직은 적용이 잘 되고 있는지 아닌지 조차 파악하기 어려운 경우가 많다.
  • 그래서 이런 기술 지원 로직들은 가급적 수동 빈 등록을 사용해서 명확하게 들어내는 것이 좋다.

애플리케이션에 광범위하게 영향을 미치는 기술 지원 로직(객체)는  수동 빈으로 등록해서 딱! 설정 정보에 바로 나타나게 하는 것이 유지보수 하기 좋다.

 참고

• 스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈들은 예외
  • 이런 부분들은 스프링 자체를 잘 이해하고 스프링의 의도대로 잘 사용하는게 중요하다.
  • 스프링 부트의 경우 DataSource 같은 데이터베이스 연결에 사용하는 기술 지원 로직까지 내부에서 자동으로 등록하는데, 이런 부분은 매뉴얼을 잘 참고해서 스프링 부트가 의도한대로 편리하게 사용하면 된다.
  • 스프링 부트가 아니라 내가 직접 기술 지원 객체를 스프링 빈으로 등록한다면 수동으로 등록해서 명확하게 들어내는 것이 좋다.

 

 

마치며

• 기술 지원 로직(객체)는 한  눈에 딱 볼 수 있게 설정 파일을 따로 만들어 수동 빈 등록을 사용하자.
• 자동 빈 등록은 편리하고 직접 개발 하였으면 한 눈에 보이지만 , 인터페이스에 대한 구현체가 여러개이면 어떤 구현체가 주입되는지 확인할려면 코드를 직접 다 뒤져봐야 한다.
• 수동 빈 등록은 구현체가 여러 개 존재하고 , 클라이언트의 사용 구분 마다 구현체가 달라진다면 수동 빈 등록을 사용하는게 보기 편할 것 같다. (이렇게 하여도 구현체의 메소드는 직접 다 뒤져 봐야할 것 같다.)

 

출처

스프링 핵심 원리 - 기본편 - 인프런