해결된 질문
작성
·
205
0
ItemServiceApplication에서 @Import를 통해서 config를 임포트 받는 이유가 무엇인가요? 로드맵 첫 강의인 스프링 입문에서는 @Import를 해주지 않았는데 본 강의에서는 적용되어있는 이유가 궁금합니다. 또 config 패키지로 구분되어있는 곳의 config 하나를 (메모리컨피그를 이용했습니다) itemservice패키지 바로 하위로 이동하여 주었고 Itemservice패키지 하위로 이동한뒤 ItemServiceApplication에서 @Import를 제거하니까 실행이 안되는데 그 이유가 있나요?
답변 1
0
안녕하세요. 양치잘하기님, 공식 서포터즈 y2gcoder입니다.
이번 강의는 다양한 DB 접근 기술 에 대해서 학습하는 강의이기 때문에 각 DB 접근 기술로 구현한 Repository 와 해당 Repository 들에 의존하는 Service 까지 굉장히 자주 바꿔줘야 하는 강의입니다! 그래서 Service, Repository는 @Configuration + @Bean 의 수동 빈 등록 방법으로 빈을 교체하는 방법을 사용해서 저희에게 명시적으로 구현 기술을 변경하는 모습을 보여주고 있는 것이 해당 강의의 매력 포인트 중 하나라고 생각합니다.
이를 위해서 메인 애플리케이션에서는 자동 빈 등록하기 위한 컴포넌트 스캔 범위를 제한해놨습니다.
위에서 @SpringBootApplication(scanBasePackages = "hello.itemservice.web")
을 보시면 scanBasePackages 를 통해 hello.itemservice.web 과 그 하위 패키지만 컴포넌트 스캔 범위로 지정한 것을 보실 수 있습니다. 이렇게 하면 해당 패키지 위치(+하위 패키지)의 @Component(+@Service, @Repository, @Controller) 만 자동으로 빈 등록하게 됩니다.
컴포넌트 스캔 범위를 제한하면 다른 패키지에 있는 @Configuration 이 달린 설정 클래스도 해당 컴포넌트 스캔 범위에 없으면 등록되지 않습니다. 그래서 이러한 설정 클래스를 스프링 애플리케이션 구동시 빈으로 등록해서 해당 설정 클래스 + 설정 클래스에 있는 @Bean 까지 수동으로 빈 등록해주도록 하는 애노테이션이 @Import(MemoryConfig.class)라고 생각하시면 됩니다 🙂 해당 애노테이션의 뜻은 MemoryConfig를 설정 클래스로 등록하고 거기의 빈들도 수동으로 빈 등록해주겠다는 뜻입니다.
결론은 컴포넌트 스캔 범위를 제한적으로 했기 때문에 궁금해하시는 모든 현상이 발생했다고 이해해주시면 감사하겠습니다!
감사합니다.