7. 의존관계 자동 주입

 

강의 내용

 

 

의존관계 주입 방법은 크게 4가지다.

 

생성자 주입

수정자 주입(setter 주입)

필드 주입

일반 메서드 주입

 

생성자 주입을 쓰면 된다는것을 기억하자

 

-> 불변하고, 누락 방지 가능하기 때문.

 

 

 

불변하다?

 

대부분의 의존관계 주입은 한번 일어나면 애플리케이션 종료시점까지 의존관계를 변경할 일이 없다.

 

오히려 대부분의 의존관계는 애플리케이션 종료 전까지 변하면 안된다.(불변해야 한다.)

 

수정자 주입을 사용하면, setXxx 메서드를 public으로 열어두어야 한다.

 

누군가 실수로 변경할 수 도 있고, 변경하면 안되는 메서드를 열어두는 것은 좋은 설계 방법이 아니다.

 

생성자 주입은 객체를 생성할 때 딱 1번만 호출되므로 이후에 호출되는 일이 없다. 따라서 불변하게 설계할 수 있다.

 

누락방지?

 

생성자 주입을 사용하면 다음처럼 주입 데이터를 누락 했을 때 컴파일 오류가 발생한다.

 

OrderServiceImpl orderService = new OrderServiceImpl();

 

당연하게도 파라미터를 안넘겨주니까 에러 뜨는데, 컴파일 오류는 사랑이니까 좋다.

 

 

수정자 주입은 그나마 좀 쓰인다고 한다.

 

 

 

 

Lombok

 

롬복을 쓰면 개발이 참 편하다.

 

예를들면

 

@RequiredArgsConstructor 의 사용을 보자

 

@Component
@RequiredArgsConstructor
public class OrderServiceImpl implements OrderService {
 private final MemberRepository memberRepository;
 private final DiscountPolicy discountPolicy;
}

이러면 

 

public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy
discountPolicy) {
 this.memberRepository = memberRepository;
 this.discountPolicy = discountPolicy;
}

이 생성자 코드가 없어도 자동으로 만들어준다.

 

생성자가 하나면  @Autowired 또한 스프링에서 자동으로 붙혀주니까, 참 편하다.

 

getter setter constructor에게 손이 고통받는걸 훨씬 줄여준다...

 

 

 

 

빈 조회 중복

 

스프링 빈을 조회했는데 2개 이상이면 어떻게 될까?

 

-> 에러가 뜬다.

 

그럼해결 방법은?

 

@Autowired 필드 명, @Qualifier, @Primary 등이 있다고 했었다.

 

@Primary보다 @Qualifier가 상세하고, 대부분 상세한 동작은 우선순위가 더 높다.

 

 

조회 빈이 2개 이상인데 전부 필요하면?

 

->List, Map 사용

 

public DiscountService(Map<String, DiscountPolicy> policyMap,
List<DiscountPolicy> policies) {
 this.policyMap = policyMap;
 this.policies = policies;
 System.out.println("policyMap = " + policyMap);
 System.out.println("policies = " + policies);
 }

DI 하면 맵과 리스트에 빈이 전부 들어간다.

 

사용 예시는, 쇼핑몰에서 클라이언트가 직접 할인 정책을 선택하는 상황 등이 있다.

 

맵에 정책이 둘 다 들어가있으니, 선택이 가능한것이다.

 

 

 

 

자동, 수동의 올바른 실무 운영 기준

 

-> 자동이 기본, 수동은 특수한 상황

 

그게 무슨말?

 

애플리케이션 로직은 2개로 구분 가능하다.

 

업무 로직 빈: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.

 

기술 지원 빈: 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다.

 

이 중에서 기술 지원 빈은 수동 등록하면 좋다.

 

딱 보면 아 구조가 이렇게 되있구나...하고 볼 수 있으니까 라고 한다.

 

근데 이부분은 솔직히 아직 잘 안와닿는다.

 

사실 그게 당연하지,,, 기억해뒀다가 프로젝트 하거나 회사갔을때 쓰도록 하자.