이 게시글은 인프런의 유료 강의 스프링 핵심 원리 - 기본편을 수강하며 공부한 내용을 담고있습니다.
저작권에 의해 강의내용에 해당하는 전체 코드는 공개할 수 없습니다.
저작권에 의해 모든 내용을 담을 수 없습니다. 중복 및 반복되는 내용은 생략했습니다.
자동 빈 등록
앞서 포스팅에서 수동 등록을 공부한 뒤에 자동 등록을 공부했다.
자동 등록을 공부할 때 ‘수십, 수백개의 빈을 일일히 등록하기 어렵다’는 이유로 자동 빈 등록 방법을 써야한다고 했다.
반대로 귀찮은 수동 등록을 내가 아닌 다른 팀원이 작성했다고 가정하고 상상을 해보자. 그럼 수동 등록 방법이 좋을까? 그래도 문제가 있다.
내가 만약 이 프로그램을 나중에 수정해야할 일이 생겼을 때 Bean 이 작성된 수십, 수백개의 파일에서 내가 원하는 파일을 찾으려면 상당히 고역일 것이다.
따라서 Controller, Service, Repository 등 동일한 패턴을 가지는 것들 그리고 유지보수가 거의 필요없는 것들은 자동 빈 등록을 사용하는게 좋다.
수동 빈 등록
그럼 수동 빈 등록은 언제 사용하는 것이 좋을까?
- 유지보수가 필요한 것
- 애플리케이션 전반에 영향을 미치는 것
- 다형성을 활용하는 경우
이러한 경우에 해당되면 수동 빈 등록을 하는 것이 좋다.
마찬가지의 이유로 AppConfig 파일의 경로를 특정 패키지가 아닌 root 경로 아래에 두는 이유는 개발자가 유지보수해야하는 파일임을 알기 쉽게하고 애플리케이션 전반에 영향을 미친다는 의미를 내포하고 있다.
비즈니스 로직에서 다형성을 활용하는 경우는?
- member 패키지
- memberService.java
- memberRepository.java
- order 패키지
- orderService.java
- orderRepository.java
예를 들어 위같은 상황이라고 가정한다.
만약 누군가 다형성을 구현하기 위해 List 또는 Map 을 활용해서 한번에 여러 Repository 를 주입받는 코드를 작성해서 나에게 주었을 때, 이를 이해하기 위해서는 member 패키지와 order 패키지를 모두 찾아서 이해해야한다. 여기서는 예시가 2개지만 10개라고 생각해보자. 너무 번거롭고 어려울 것이다.
이러한 문제를 해결하려면 아예 Repository 패키지를 따로 만들어서 Repository 만 모아 놓거나 수동 빈 등록을 활용해야한다.
1
2
3
4
5
6
7
8
9
10
11
12
@Configuration
public class RepositoryConfig {
@Bean
public Repository memberRepository() {
return new MemberRepository();
}
@Bean
public Repository orderRepository() {
return new OrderRepository();
}
}
이렇게 Repository 들을 한곳에 모아서 수동으로 빈 등록을 해주면 다른사람이 이해하기 쉬워진다.