@RequiredArgsConstructor 와 @Autowired의 차이

💡 토비의 스프링 3.1 Vol1에 있는 내용을 공부해 정리하였습니다.

마지막 줄에 요약이 있으니 바쁘신 분들은 마지막 줄만 보셔도 됩니다.

 

 

 

 

의존관계 검색과 주입

의존관계 주입(DI, Dependency Injection)이외에도 의존관계 검색(DL, Dependency Lookup)이라는 것이 존재한다. 이는 의존관계를 파라미터로 주입받는 것이 아니라 자신이 필요로 하는 의존 오브젝트를 능동적으로 찾는 것을 의미한다.

 

그리고 의존관계 검색(Dependency LookUp)은 스스로 컨테이너에 요청하는 방법으로 사용된다.

public UserDao(){
	DaoFactory daoFactory = new DaoFactory()
	this.connectionMaker = daoFactory.connectionMaker()
}

즉 외부에서 주입이 아니라 스스로 IoC 컨테이너인 DaoFactory에게 요청하는 것이다.

 

 

스프링IoC 컨테이너인 애플리케이션 컨텍스트는 getBean() 이라는 방식으로 의존관계 검색을 사용한다.

 

결과적으로 보았을때 의존관계 주입(DI)이나 의존관계 검색(DL)은 모두 동일한 결과를 내지만 의존관계 검색은 다음과 같은 단점이 존재하다.

“의존관계” 검색 방법은 코드 안에 오브젝트 팩토리 클래스나 스프링 API가 나타나게 된다.

이는 애플리케이션 컴포넌트가 컨테이너와 같이 성격이 다른 오브젝트에 의존하게 되는 것이므로 바람직하지 않다.

그렇지만 테스트 코드를 작성할때는 의존관계 검색을 사용해야만 한다. 테스트 코드에서 main() 메소드가 없기 때문에 DI를 통해서 의존관계 주입이 안되기 때문이다. 즉 스프링 컨테이너에 담긴 오브젝트를 사용하려면 의존관계 검색 방식을 이용해 사용해야 하는데 테스트 코드에는 main()메서드가 없어 의존관계 주입을 할 수 없다.

 

 

의존관계 검색(DL)에는 다음과 같은 장점도 있는데

검색하는 오브젝트는 자신이 스프링의 빈일 필요가 없다는 점이다.

 

추가

➕의존관계를 주입 받는 메소드 파라미터가 이미 특정 클래스 타입으로 고정되어 있다면 DI가 일어날 수 없다. 그렇기에 인터페이스를 이용한 다형성으로 주입받아야한다.

➕스프링을 사용하면 LomBok의@RequiredArgsConstructor와 @Autowired는 의존관계를 맺어주지만 그 방식에 차이가 있다.

그렇기 때문에 Junit을 이용한 테스트 코드를 작성시에도 @RequiredArgsConstructor 를 통해서 코드를 작성할 경우 의존관계 주입이기 때문에 정상적으로 동작하지 않는다.