Spring DI 방법

Field Injection

가장 간단한 방법으로 Bean으로 등록된 객체를 사용하고자 하는 클래스에 Field로 선언한 뒤 @Autowired 키워드를 붙여주면 자동으로 주입됩니다.

@Service
public class BoardService {

    @Autowired
    private BoardDao boardDao;

    public void doSomething() {
        // ....
    }
}

동일한 Class의 Bean이 여러 개 전재하는 경우에는 아래와 같이 @Qualifier(“myBoardDao”)를 붙여주어 Bean 이름을 지정해 주입 받는 것이 가능합니다.

@Service
public class BoardService {

    @Autowired
    @Qualifier("myBoardDao")
    private BoardDao boardDao;

    public void doSomething() {
        // ....
    }
}

Field Injection의 단점

단일 책임의 원칙 위반
의존성을 주입하기가 매우 쉽습니다. @Autowired 선언 아래 여러 개를 추가할 수 있기 때문입니다. 이 말은 하나의 클래스가 많은 책임을 가지게 될 수 있다는 의미입니다.

의존성이 숨는다
DI 컨테이너를 사용한다는 것은 클래스가 자신의 의존성만 책임진다는 것이 아닙니다. 제공된 의존성 또한 책임집니다. 그래서 클래스가 어떤 의존성을 책임지지 않을 때, 메서드나 생성자를 통해 확실히 커뮤니케이션이 되어야 합니다. 그러나 Field Injection은 숨은 의존성만 제공해줍니다.

DI 컨테이너의 결합성과 테스트 용이성
DI 프레임워크의 핵심 아이디어는 관리되는 클래스가 DI 컨테이너에 의존성이 없어야 합니다. 즉, 필요한 의존성을 전달하면 독립적으로 인스턴스화 할 수 있는 단순 POJO여야 합니다. DI 컨테이너 없이도 Unit Test에서 인스턴스화 시킬 수 있고, 각각 나누어서 테스트도 할 수 있습니다. 컨테이너의 결합성이 없다면 관리하거나 관리하지 않는 클래스를 사용할 수 있고, 심지어 다른 DI 컨테이너로 전환할 수 있습니다. 하지만, Field Injection을 사용하면 필요한 의존성을 가진 클래스를 곧바로 인스턴스화 시킬 수 없습니다.

불변성
Field Injection은 final을 선언할 수 없습니다. 그래서 객체가 변할 수 있습니다.

Setter Injection

Setter Method에 @Autowired를 붙여서 DI를 구현하는 방식입니다. 자유롭게 의존성을 주입할 수 있다는 장점이 있습니다. 반면에, 실제 Runtime 환경에서도 알 수 없는 맥락에서 의존성 변경에 대한 위험이 있습니다.

@Service
public class BoardService {

    private BoardDao boardDao;

    @Autowired
    public void setBoardDao(BoardDao boardDao) {
        this.boardDao = boardDao;
    }
}

Constructor Injection

현재 가장 권장되고 있는 방법입니다. 하나의 생성자가 존재 시, 기존 Field Injection의 거의 모든 단점을 극복해낸 패턴입니다

@Service
public class BoardService {

    private BoardDao boardDao;

    // @Autowired Spring 4.3 버젼 부터 @Autowired 생략가능
    public BoardService(BoardDao boardDao) {
        this.boardDao = boardDao;
    }
}.