스프링 입문 - 자바 코드로 직접 스프링 빈 등록하기

저번시간에는,@Service, @Repository, @Autowired, 등을 이용하여
컴포넌트 스캔으로  스프링 컨테이너에 스프링빈으로 자동으로 등록하고, 연결하는 것을 자동으로 했는데,

이번시간에는, 자바 코드로 하나하나 직접 스프링 빈을 등록해보도록 하겠다.

MemberService와 MemberRepository의 @Service, @Repository, @Autowired 애너테이션을 제거하고 진행하도록 하자. (MemberController 는 그대로 둔다.)

지우고나서 돌려보면,

당연히 스프링이 올라올 때 컴포넌트 스캔이 안되므로, MemberService가 스프링빈에 등록되어있지 않다.
그래서 이처럼 오류가 난다.

 

컴포넌트 스캔방식 말고, 직접 등록하는 방식에 대해 알아보자.

SpringConfig라는 이름으로 해당위치에 파일을 생성했다.

그리고 @Configuration을 작성해준다.

이렇게 작성을 해주는데,
@Bean 애너테이션은,
스프링이 뜰 때, @Configuration을 읽고, "@Bean은 스프링 빈에 등록하라는 뜻이네!" 라고 스프링이 인식을해서
memberService()를 호출해서 스프링빈에 등록을 해준다.

그런데, MemberService();에 빨간줄이 있는 것은, 생성자에서 뭔가를 넣어줘야한다.
Cmd+p 를 눌러서 확인해보면, MemberRepoeitory를 넣어줘야 하는것을 확인할 수 있다.

MemberRepository를 @Bean으로 등록해주었다.
MemberRepository는 인터페이스라서, 구현체인 MemoryMemberRepository를 new에  해주었다.

그러면, MemberService에는 방금 작성한 @Bean에 있는 memberRepository를 넣어줘야 한다.

이렇게 넣어주면 된다.

 

그러면은 이게 스프링에 뜰때 어떻게 뜨냐면,
MemberService와 MemberRepository를 둘다 스프링빈에 등록을 하고,
그러면서, 스프링빈에 등록되어 있는 memberRepository를 MemberService에 넣어준다.

그러면 이러한 그림이 완성이 된다.

@Configuration

@Bean

이것들을 이용해서 직접 스프링 빈에 등록할 수 있다.

 

그런데, @Controller는 어쩔 수 없다.
컨트롤러는 어쨋든 스프링이 관리하는 대상이기 때문에 이렇게 두면 컴포넌트 스캔이 올라가고,
컴포넌트 스캔이기 때문에 @Autowired로 연결해준다.

이렇게 해두면, @Bean으로 등록한 memberService가 연결된다.

 

이상태로 잘 동작하는지 돌려보자.

정상적으로 잘 동작하는 것을 확인할 수 있다.

 

---

 

• XML로 설정하는 방식도 있지만 최근에는 잘 사용하지 않으므로 생략.

• DI에는 필드주입, setter주입, 생성자 주입 이렇게 3가지 방법이 있다. 의존관계 실행중에 동적으로 변한는 경우는 거의 없으므로 생성자 주입을 권장한다.

우리가 작성했던 이 코드처럼, 생성자를 통해서 MemberService가 들어오는데,
이러한 것을 생성자 주입 이라고 한다.

 

그리고 이렇게 생성자를 빼고, 아예 필드에다가 @Autowired 하는 방법이 있다.
이러한 방식을 필드 주입이라고 한다.

그런데, 인텔리제이가 @Autowired 밑에 물결표시를 했다. 뭔가 애매한가보다.
살펴보면, Create constrouctor 라고 나온다.

필드주입은 별로 좋지 않은 방법이다.

왜냐하면, 스프링을 뜰떄만 얘를 넣어주고, 이후에는 중간에 바꿔치기 할 수 있는 방법이 아예없다.

 

이번에는 setter주입이다.
cmd+n 으로 setter를 넣고, 여기에 @Autowired를 붙여준다.
이렇게 해주면, 생성은 생성대로 되고, setter가 나중에 호출이 되서 stter를 통해서 주입이 된다.

그런데, 이것의 단점은,
누군가가 MemberController를 호출했을 때, 이것이 public으로 열려있어야 한다.
setMemberService를 한번 세팅하고나면 중간에 바꿀일이 없지만,  public하게 노출된다는 단점이 있다.
중간에 잘못 바꾸면 문제가 생길 것이다.

 

그래서 DI방식으로는 필드주입, setter주입보다는 생성자 주입이 권장된다.

 

실무에서는 주로 정형화된 컨트롤러, 서비스, 리포지토리 같은 코드는 컴포넌트 스캔을 사용한다. 그리고 정형화 되지 않거나, 상황에 따라 구현 클래스를 변경해야 하면 설정을 통해 스프링 빈으로 등록한다.

이 내용이 중요한 내용이다.

강의 뒤편에는 뭘 할거냐면,
현재는 MemberRepository를 만들어놨는데,

비즈니스 요구사항 정리 부분에서 언급했듯, 아직 데이터 저장소가 선정되지 않았다는 가상의 시나리오 조건이 있었다.
그래서 일단 MemoryMemberRepository로 구현했고, 나중에 교체할 것이다.

그래서 지금 인터페이스로 설계하고, 구현체로 MemoryMemberRepsoitory를 사용하는 것이다.
그런데, 나중에 이 MemoryMemberRepository를 다른 리포지토리로 바꿔치기 할 것이다.

이때, 기존에 운영중인 코드를 하나도 손대지 않고 바꿔치기 할 수 있는 방법이 있다.
그 방법을 사용하려면 나주엥 구현체를 바꿔치기 해야한다.

그러면, "상황에 따라 구현 클래스를 변경해야 하면 설정을 통해 스프링 빈으로 등록한다" 라는 상황인 것이다.

그래서 나중에  실제 데이터베이스를 연결하게되면 뭐만고치면 되냐면,

이것만 이런식으로 고치면 된다. 다른코드는 전혀 손댈필요 없이 말이다.

이것이 바로, 직접 코드로 스프링빈을 등록할 때의 장점이다.

그러나, 컴포넌트 스캔을 사용하면, 여러 코드를 바꿔야 한다.