Skip to content

Latest commit

 

History

History
578 lines (385 loc) · 17.8 KB

07_의존관계_자동_주입.md

File metadata and controls

578 lines (385 loc) · 17.8 KB
Raw

다양한 의존관계 주입 방법

  • 생성자 주입

  • 수정자 주입 (setter 주입)

  • 필드 주입

  • 일반 메서드 주입

생성자 주입

  • 생성자를 통해 의존관계를 주입 받는 방법

    • 생성자 호출 시점에 딱 1번만 호출되는 것이 보장

    • 불변, 필수 의존관계 사용

생성자가 딱 1개만 있으면 @Autowired를 생략해도 자동 주입 (스프링 빈에만 해당)

수정자 주입

  • setter 수정자 메서드를 통해 필드의 값을 변경하는 의존관계 주입 방법

    • 선택, 변경 가능성이 있는 의존관계에 적용

    • 자바빈 프로퍼티 규약의 수정자 메서드 방식을 사용

@Component
public class OrderServiceImpl implements OrderService {

   private MemberRepository memberRepository;
   private DiscountPolicy discountPolicy;

   @Autowired
   public void setMemberRepository(MemberRepository memberRepository) {
       this.memberRepository = memberRepository;
   }

   @Autowired
   public void setDiscountPolicy(DiscountPolicy discountPolicy) {
       this.discountPolicy = discountPolicy;
   }
}

@Autowired의 기본 동작에서 주입할 대상이 없으면 오류 발생 -> @Autowired(required = false)로 지정 가능

자바빈 프로퍼티: 필드의 값을 직접 바꾸지 않고 set이나 get 메서드를 통해 값을 읽거나 수정하는 규칙

컴포넌트 스캔 등록 순서

  1. 생성 단계에서는 빈 생성 시 생성자 주입 동시에 등록

  2. 이후 의존관계 주입 단계에서 수정자 주입 등록

필드 주입

  • 필드에 바로 주입하는 방법

    • 코드가 간결하지만 외부에서 변경이 불가능하여 테스트하기 어려움

    • DI 프레임워크가 없으면 아무것도 할 수 없음

    • 사용 X

      • 애플리케이션의 실제 코드와 관계 없는 테스트 코드

      • 스프링 설정을 목적으로 하는 @Configuration과 같은 곳에서 특별한 용도로 사용

순수한 자바 코드에서는 @Autowired 동작하지 않음

@Bean에서 파라미터에 의존관계는 자동 주입. 수동 등록 시 자동 등록된 빈의 의존 관계가 필요할 때 문제 해결 가능

일반 메서드 주입

  • 일반 메서드를 통해 주입 가능

    • 한 번에 여러 필드 주입 가능

    • 일반적으로 사용하지 않음

옵션 처리

  • 주입할 스프링 빈이 없어도 동작해야 할 때

  • @Autowired의 required 옵션이 true로 되어 있어 주입 대상이 없느 경우 오류가 발생

자동 주입 대상을 옵션 처리하는 방법

  1. @Autowired(required=false): 자동 주입할 대상이 없으면 수정자 메서드 자체가 호출 안됨

  2. org.springframework.lang.@Nullable : 자동 주입할 대상이 없으면 null이 입력

  3. Optional<> : 자동 주입할 대상이 없으면 Optional.empty 가 입력

public class AutowiredTest {

    @Test
    void AutowiredOption() {
        AnnotationConfigApplicationContext ac = new AnnotationConfigApplicationContext(TestBean.class);
    }

    static class TestBean {

//        의존관계가 아예 없는 경우 해당 메서드를 호출하지 않음
        @Autowired(required = false)
        public void setNoBean1(Member noBean1) {
//            관련 없는 Member을 사용
            System.out.println("noBean1 = " + noBean1);
        }

//        호출은 되지만 값이 null
        @Autowired
        public void setNoBean2(@Nullable Member noBean2) {
            System.out.println("noBean2 = " + noBean2);
        }

        @Autowired
        public void setNoBean3(Optional<Member> noBean3) {
            System.out.println("noBean3 = " + noBean3);
        }
        
    }
}
  • 출력결과
setNoBean2 = null
setNoBean3 = Optional.empty

생성자 주입을 선택해라!

최근에는 스프링을 포함한 DI 프레임워크 대부분 생성자 주입을 권장

불변

  • 대부분 의존관계 주입을 한 후 애플리케이션 종료시점까지 의존관계를 변경할 일이 없음

  • 오히려 대부분의 의존관계는 종료 전까지 변하면 안됨 (불변)

  • 수정자 주입을 사용시 set 메서드를 public으로 열어둬야 함

  • 실수로 변경할 수 있으며, 변경하면 안되는 메서드를 열어두는 것은 좋지 않은 설계 방법

  • 생성자 주입은 객체 생성 시 딱 1번만 호출되며 이후에 호출되면 안됨 -> 불변하게 설계

누락

  • 생성자 주입을 사용했을 때 주입 데이터를 누락한 경우 컴파일 오류가 발생

  • IDE에서 바로 어떤 값을 필수로 주입해야 하는지 알 수 있음

final 키워드

  • final 키워드가 붙은 변수는 초기화 후 변경할 수 없음

  • 생성자 주입을 사용하면 필드에 final 키워드를 사용 가능

  • 생성자에서 혹시라도 값 설정이 안 된 경우 컴파일 시점에서 막아줌

컴파일 오류는 세상에서 가장 빠르고, 좋은 오류!

수정자 주입을 포함한 나머지 주입 방식은 모두 생성자 이후에 호출되는 방식으로 필드에 final 키워드를 사용할 수 없음

오직 생성자 주입 방식만 final 키워드 사용 가능능

정리

  • 프레임 워크에 의존하지 않으면서 순수한 자바 언어의 특징을 잘 살리는 이유로 생성자 주입 방식을 선택

  • 생성자 주입과 수정자 주입을 동시 사용 가능

    • 기본으로 생성자 주입을 사용, 필수 값이 아닌 경우에는 수정자 주입 방식을 옵션으로 부여

  • 항상 생성자 주입을 선택!

    • 가끔 옵션이 필요하면 수정자 주입을 선택

    • 필드 주입은 사용하지 않는게 좋음

롬복과 최신 트랜드

롬복 라이브러리 적용 방법

  • File -> Settings -> plugins -> lombok 검색 설치

image

  • File -> Annotation Processors 검색 -> Enable annotation processing 체크

image

@Getter, @Setter

package hello.core;

import lombok.Getter;
import lombok.Setter;
import lombok.ToString;

@Getter
@Setter
@ToString
public class HelloLombok {
    private String name;
    private int age;

    public static void main(String[] args) {
        HelloLombok helloLombok = new HelloLombok();
        helloLombok.setName("hello");
        System.out.println("helloLombok = " + helloLombok);
        String name = helloLombok.getName();
        System.out.println("name = " + name);
    }
}
  • get, set 메서드를 따로 설정할 필요없이 사용 가능

@RequiredArgsConstructor

  • final이 붙은 필드를 모아 생성자를 자동으로 만들어줌
@Component
@RequiredArgsConstructor // final이 붙은 필수값의 생성자를 만들어준다.
public class OrderServiceImpl implements OrderService {

    private final MemberRepository memberRepository;
    private final DiscountPolicy discountPolicy;

//    @Autowired
//    public OrderServiceImpl(MemberRepository memberRepository, DiscountPolicy discountPolicy) {
//        this.memberRepository = memberRepository;
//        this.discountPolicy = discountPolicy;
//    }
  • 주석 처리한 생성자 메서드를 @RequiredArgsConstructor 하나로 처리할 수 있다.

조회 빈이 2개 이상 - 문제

  • @Autowired는 타입(Type)으로 조회

ac.getBean(DiscountPolicy.class)

  • 코드와 유사하게 작동(더 많은 기능을 제공)

  • 타입으로 조회 시 선택된 빈이 2개 이상일 때 문제가 발생

NoUniqueBeanDefinitionException: No qualifying bean of type
'hello.core.discount.DiscountPolicy' available: expected single matching bean
but found 2: fixDiscountPolicy,rateDiscountPolicy

  • 하나의 빈을 기대했지만 2개의 빈이 발견되었다.

  • 하위 타입을 지정할 수 있지만 이는 DIP를 위배하고 유연성이 떨어진다.

  • 추가로 이름만 다르고 완전히 같은 타입의 스프링 빈이 2개인 경우에는 해결할 수 없다.

@Autowired 필드 명, @Qualifier, @Primary

@Autowired 필드 명 매칭

  • @Autowired는 타입 매칭을 시도할 때 여러 빈이 있으면 필드 이름, 파라미터 이름으로 빈 이름을 추가 매칭한다.
@Autowired
private DiscountPolicy discountPolicy

기존 코드

@Autowired
private DiscountPolicy rateDiscountPolicy

필드 명을 빈 이름으로 변경

  • 필드 명 매칭은 먼저 타입 매칭을 시도한 후 그 결과에 여러 빈이 있을 시 추가로 동작하는 기능

@Autowired 매칭 정리

  1. 타입 매칭

  2. 2개 이상의 타입 매칭 결과 시, 필드 명, 파라미터 명으로 빈 이름 매칭

@Qualifier 사용

  • 추가 구분자를 붙여주는 방식

  • 빈 이름을 변경하는 것은 아님

@Component
@Qualifier("mainDiscountPolicy")
public class RateDiscountPolicy implements DiscountPolicy {}

빈 등록 시 @Qualifier를 붙여준다.

주입할 때 @Qualifier을 붙여준 후 등록한 이름을 적어준다.

@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
 @Qualifier("mainDiscountPolicy") DiscountPolicy
discountPolicy) {
 this.memberRepository = memberRepository;
 this.discountPolicy = discountPolicy;
}

생성자 자동 주입

@Autowired
public DiscountPolicy setDiscountPolicy(@Qualifier("mainDiscountPolicy")
DiscountPolicy discountPolicy) {
 this.discountPolicy = discountPolicy;
}

수정자 자동 주입

@Bean
@Qualifier("mainDiscountPolicy")
public DiscountPolicy discountPolicy() {
 return new ...
}

빈 등록시 자동 주입

  • @Qualifier는 @Qualifier를 찾는 용도로만 사용하는 것이 명확하다.

@Qualifier 정리

  1. @Qualifier끼리 매칭

  2. 빈 이름 매칭

  3. NoSuchBeanDefinitionException 예외 발생

@Primary 사용

  • 우선 순위를 정하는 방법

  • 여러 빈이 매칭되면 @Primary가 우선권을 가짐

@Component
@Primary
public class RateDiscountPolicy implements DiscountPolicy {}
@Component
public class FixDiscountPolicy implements DiscountPolicy {}

rateDiscountPolicy가 우선권을 가짐

이 후 기존과 동일한 코드로 동작이 가능

//생성자
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
 DiscountPolicy discountPolicy) {
 this.memberRepository = memberRepository;
 this.discountPolicy = discountPolicy;
}
//수정자
@Autowired
public DiscountPolicy setDiscountPolicy(DiscountPolicy discountPolicy) {
 this.discountPolicy = discountPolicy;
}

@Primary, @Qualifier 활용

주로 사용하는 메인 데이터베이스와 (특별한 기능) 가끔 사용하는 서브 데이터베이스 각각의 커넥션을 담당하는 스프링 빈이 있다고 가정하자.

  • 메인 데이터베이스의 커넥션을 획득하는 스프링 빈은 @Primary를 적용하여 조회하는 방식

  • 서브 데이터베이스 커넥션 빈을 획득할 때는 @Qualifier로 지정하여 명시적으로 획득하는 방식

메인 데이터베이스의 스프링빈을 등록할 때 @Qualifier을 지정해도 상관 없음

우선순위

  • @Primary는 기본값처럼 동작

  • @Qualifier는 매우 상세하게 동작

스프링은 자동보단 수동, 넓은 범위의 선택권 보단 좁은 범위의 선택권이 우선 순위가 높다.

  • @Qualifier이 우선권이 높다.

애노테이션 직접 만들기

@Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER,
ElementType.TYPE, ElementType.ANNOTATION_TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Qualifier("mainDiscountPolicy")
public @interface MainDiscountPolicy {
}
@Component
@MainDiscountPolicy
public class RateDiscountPolicy implements DiscountPolicy {}
//생성자 자동 주입
@Autowired
public OrderServiceImpl(MemberRepository memberRepository,
 @MainDiscountPolicy DiscountPolicy discountPolicy) {
 this.memberRepository = memberRepository;
 this.discountPolicy = discountPolicy;
}
//수정자 자동 주입
@Autowired
public DiscountPolicy setDiscountPolicy(@MainDiscountPolicy DiscountPolicy
discountPolicy) {
 this.discountPolicy = discountPolicy;
}
  • 직접 애노테이션을 만들어 적용이 가능하다.

애노테이션은 상속이라는 개념이 없음

조회한 빈이 모두 필요할 때, List, Map

  • 특정 타입의 스프링 빈이 모두 필요한 경우
public class AllBeanTest {

    @Test
    void findAllBean() {
        ApplicationContext ac = new AnnotationConfigApplicationContext(AutoAppConfig.class, DiscountService.class);
        DiscountService discountService = ac.getBean(DiscountService.class);
        Member member = new Member(1L, "userA", Grade.VIP);
        int discountPrice = discountService.discount(member, 10000, "fixDiscountPolicy");
        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);
    }
    static class DiscountService {
        private final Map<String, DiscountPolicy> policyMap;
        private final List<DiscountPolicy> policies;
        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);
        }
        public int discount(Member member, int price, String discountCode) {
            DiscountPolicy discountPolicy = policyMap.get(discountCode);
            System.out.println("discountCode = " + discountCode);
            System.out.println("discountPolicy = " + discountPolicy);
            return discountPolicy.discount(member, price);
        }
    }
}

로직 분석

  • DiscountService는 Map을 통해 모든 DiscountPolicy를 주입 받음. (fixDiscountPolicy, rateDiscountPolicy)

  • discount() 메서드는 "fixDiscountPolicy"가 입력되면서 map에서 fixDiscountPolicy 스프링 빈을 찾아 실행

주입 분석

  • Map<String, DiscountPolicy> : map의 키에 스프링 빈 이름을 넣어주고, DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아줌

  • List : DiscountPolicy 타입으로 조회한 모든 스프링 빈을 담아줌

  • 해당하는 스프링 빈이 없으면 빈 컬렉션이나 Map을 주입

참고 - 스프링 컨테이너를 생성하면서 스프링 빈 등록하기

new AnnotationConfigApplicationContext(AutoAppConfig.class,DiscountService.class);

  • new AnnotationConfigApplicationContext()을 통해 스프링 컨테이너를 생성

  • AutoAppConfig.class , DiscountService.class를 파라미터로 넘기면서 해당 클래스를 자동으로 스프링 빈으로 등록

즉, 스프링 컨테이너를 생성하면서 두 클래스를 스프링 빈으로 자동 등록한다.

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

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

결론: 점점 자동을 선호하는 추세

자동 빈 등록을 사용해도 OCP, DIP를 지킬 수 있음

자동: 스프링 빈을 등록할 때 @Component만 넣어주면 되는 일

수동: @Configuration 설정 정보에서 @Bean을 적고, 객체를 생성하고, 주입할 대상을 일일히 적어주는 과정

  • 관리할 빈이 많아 설정 정보가 커지면 설정 정보를 관리하는 것 자체도 부담

언제 수동 빈 등록을 사용하는 것이 좋을까

애플리케이션을 크게 업무 로직과 기술 지원 로직으로 나누어 생각

  • 업무 로직 빈

    • 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리 등 모두 업무 로직.

    • 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경

    • 숫자도 매우 많고, 개발 시 컨트롤러, 서비스, 리포지토리와 같은 어느정도 유사한 패턴

    • 해당 경우 자동 기능을 사용하는 것이 좋음

    • 보통 문제가 생겨도 어떤 곳에서 발생했는지 명확하게 파악할 수 있음

  • 기술 지원 빈

    • 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용

    • 데이터베이스 연결이나, 공통 로그 처리와 같은 업무 로직을 지원하기 위한 하부 기술이나 공통 기술

    • 업무 로직에 비해 그 수가 매우 적고, 보통 애플리케이션 전반에 걸쳐 광범위하게 영향을 미침

    • 적용이 잘 되고 있는지 파악하기 어려운 경우가 많음

    • 가급적 수동 빈 등록으로 명확하게 드러내는 것이 좋음

  • 애플리케이션에 광범위하게 영향을 미치는 기술 지원 객체는 수동 빈으로 등록해 설정 정보에 나타나게 하는 것이 유지보수에 적합.

비즈니스 로직 중에서 다형성을 적극 활용할 때

어떤 빈 들이 주입되며 각 빈들의 이름이 무엇인지 코드만 보고 확인이 필요할 때

  • 수동 빈으로 등록하거나 자동으로 하되 특정 패키지에 같이 묶어두는 것이 좋다.
@Configuration
public class DiscountPolicyConfig {

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

스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈들은 예외

본인이 직접 기술 지원 객체를 스프링 빈으로 등록한다면 수동으로 등록해서 명확하게 드러내는 것이 좋다.

정리

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

  • 직접 등록하는 기술 지원 객체는 수동 등록

  • 다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자.