10-2. 다양한 의존관계 주입방법 (애노테이션을 만들기, List Map으로 받기

애노테이션 만들어서 의존관계 주입하기

필요이유

의존 관계 주입 방식 중 @Qqualifier의 단점을 보면

 

OrderServiceImpl.java

 

RateDiscountPolicy.java

- 해당 하는 Qualifier안에 들어가는 문자는 타입으로 조회하기 때문에 오타가 날 수 있다.

 

즉 아래와 같이 오타가 날수 있는데 실행시 이름이 일치 하지않아 UnsatisfiedDependencyException에러가 나는데 이런 실수는 자주 있을수 있다.

 

만들어보기

MainDiscountPolicy.java

- 클래스에 있는 애노테이션은 Qqualifier.java파일에 그대로 가져왔다.

- @Qualifier 부분은 추가한 것인데 해당 애노테이션을 쓰면 해당 부분이 적용된다.

 

적용

OrderServiceImpl.java

 

RateDiscountPolicy.java

 

 

참고

애노테이션은 상속의 개념이 없고 위와 같이 상속처럼 애노테이션을 사용하는 기능은 스프링이 지원해주는 기능이다.

 

조회한 빈이 모두 필요할 때 List, Map으로 받기

- 의도적으로 스프링 빈이 모두 필요한 경우 List, Map으로 받아서 의도에 맞에 사용가능하다.

 

DiscountService.java

- Map으로 받은 빈을 상황에 따라 다르게 사용할 service로 DiscountService에서 Map으로 모든 DiscountPolicy를 주입받는다.

이후 discount에서 get을 사용하여 파라미터로 받은 빈이름으로 대상을 받아 로직을 처리한다.

 

test메서드

- 먼저 DiscountService.class 에 빈 주입이 필요하여 ApplicationContext에 대상을 추가했다.

 

=>이런 다형성을 활용하는 경우 수동빈으로 의존관계를 등록하는게 보기에 좋고 자동으로 할경우 패키지로 묶는게 보기 편하다.

자동, 수동 의존관계 주입 어떤걸 사용해야 할까?

- 기본적으로 편리한 자동을 사용하는게 좋다.

- 현재 점점 자동을 선호하는 추세로 @Component뿐 아리라 @Controller, @Service, @Repository 처럼 계층을 맞춰서 자동 스캔 할수록 지원 하고 있다.

- 스프링 부트도 컴포넌트 스캔을 기본으로 사용한다.

 

 

애플리케이션 로직을 나눠보면

1) 업무 로직 빈 : 컨트롤러, 서비스, 리포지토리등 비지니스 로직

2) 기술지원빈 : DB, 로그설정 등의 전반적인 공통 업무 지원 로직

 

- 업무로직은 대상 숫자가 매우 많고 컨트롤러 - 서비스 - 리포지토리처럼 패턴이 있어 자동의존관계 주입을 적극 사용하는게 좋다.

- 기술지원 로직은 숫자가 적고 애플리케이션 전반에 영향을 미치기 때문에 가급적 수동빈으로 명확히 드러내는게 좋다.

 

---

 

 

 

자료출처

스프링 핵심 원리 - 기본편

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/dashboard