스프링 - 2022-4-13

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

• List 혹은 Map을 활용해 스프링 빈에 등록된 빈들을 한번에 주입이 가능하다.
• Map<String, DiscountPolicy>라 하면 String에는 빈 이름이 들어간다.

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, "rateDiscountPolicy");
        assertThat(discountService).isInstanceOf(DiscountService.class);
        assertThat(discountPrice).isEqualTo(1000);

        int rateDiscountPrice = discountService.discount(member, 20000, "rateDiscountPolicy");
        assertThat(rateDiscountPrice).isEqualTo(2000);
    }

    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);
        }
    }
}

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

• 기본 설정으로는 자동으로 해놔야 좋다
• 점점 자동으로 진화하는 추세인 스프링
• 자동 빈 등록을 해도 OCP, DIP 다 만족시켜준다
• 수동 빈 등록 사용
  • 애플리케이션은 크게 업무 로직과 기술 지원 로직으로 나눌 수 있다.
  • 업무 로직 빈: 웹을 지원하는 컨트롤러, 핵심 비즈니스 로직이 있는 서비스, 데이터 계층의 로직을 처리하는 리포지토리등이 모두 업무 로직이다. 보통 비즈니스 요구사항을 개발할 때 추가되거나 변경된다.
  • 기술 지원 빈: 기술적인 문제나 공통 관심사(AOP)를 처리할 때 주로 사용된다. 데이터베이스 연결이나, 공통 로그 처리 처럼 업무 로직을 지원하기 위한 하부 기술이나 공통 기술들이다.
  • 업무 로직은 숫자가 많고, 컨트롤러, 서비스, 리포지토리처럼 어느정도 유사한 패턴들이 있다. 이런 경우 자동 기능을 적극 사용하는 것이 좋다. 보통 문제가 발생해도 어떤 곳에서 문제가 생겼는지 명확하게 파악하기 쉽다.
  • 기술 지원 로직은 업무 로직과 비교해서 그 수가 매우 적고, 보통 애플리케이션 전반에 걸쳐서 광범위하게 영향을 미친다. 그리고 업무 로직은 문제가 발생했을 때 어디가 문제인지 명확하게 잘 들어나지만, 기술 지원 로직은 적용이 잘 되고 있는지 아닌지 조차 파악하기 어려운 경우가 많다. 그래서 이런 기술 지원 로직들은 가급적 수동 빈 등록을 사용해서 명확하게 들어내는 것이 좋다.
• 의존관계 자동 주입에서 List, Map으로 조회하면 다른 개발자가 볼 때 어떤 빈들이 주입될 지, 각 빈들의 이름이 무엇인지 코드를 보고 한번에 파악하기 어렵다. 여러 코드들을 찾아봐야한다.
• 이런 경우 수동 빈으로 등록하거나 특정 패키지에 같이 묶어두는 것이 좋다. → 유지보수에 유리
• 스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈들은 예외다. 이런 부분들은 스프링 자체를 잘 이해하고 스프링의 의도대로 잘 사용하는게 중요하다. 스프링 부트의 경우 DataSource 같은 데이터베이스 연결에 사용하는 기술 지원 로직까지 내부에서 자동으로 등록하는데, 이런 부분은 메뉴얼을 잘 참고해서 스프링 부트가 의도한 대로 편리하게 사용하면 된다. 반면에 스프링 부트가 아니라 내가 직접 기술 지원 객체를 스프링 빈으로 등록한다면 수동으로 등록해서 명확하게 들어내는 것이 좋다.

<정리>

• 편리한 자동 기능 기본으로 사용하자.
• 직접 등록하는 기술 지원 객체는 수동 등록
• 다형성을 적극 활용하는 비즈니스 로직은 수동 등록을 고민해보자

빈 생명주기 콜백

• 스프링은 객체 생성 후 의존관계 주입을 한다. → 생성자 주입은 예외
• 스프링 빈 라이프사이클
  • 스프링 컨테이너 생성 → 스프링 빈 생성 → 의존관계 주입 → 초기화 콜백 → 사용 → 소멸전 콜백 → 스프링 종료
• 스프링은 다양한 방식으로 생명주기 콜백을 지원
• 객체의 생성과 초기화를 분리하자.