작성
·
230
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를 설정 클래스로 등록하고 거기의 빈들도 수동으로 빈 등록해주겠다는 뜻입니다.
결론은 컴포넌트 스캔 범위를 제한적으로 했기 때문에 궁금해하시는 모든 현상이 발생했다고 이해해주시면 감사하겠습니다!
감사합니다.
맞습니다
@SpringBootApplication(scanBasePackages = "패키지경로")
: 주 학습 범위가 아닌 것들은 컴포넌트 스캔으로 빈을 등록해서 간편하게 사용@Import(MemoryConfig.class)
: 테스트를 위해 구현체를 계속 변경해야 할 필요가 있는 곳은 수동으로 빈을 등록해 변화를 명시적으로 표현
이라고 생각해주시면 감사할 것 같슴다!
설명 감사드립니다. 저도 비슷한 고민으로 선질문답변을 검색중에 좋은 답변을 구한것같아요.
정리하자면,
@SpringBootApplication(scanBasePackages = "패키지경로")
: 실습마다 패키지경로를 바꿔가며 변동을 줄 집단적 영역지정이고
@Import(MemoryConfig.class)
: 변하지 않게 고정시키고 싶은 개별적 지정일 때 사용하는 것
위 처럼 정리할 수 있을까요?