• 애플리케이션 구성 단순화: DI를 사용하면 애플리케이션 구성 과정을 크게 단순화할 수 있습니다. 또한, 다양한 방식을 사용해 다른 클래스에 주입할 클래스를 구성할 수 있습니다. 동일한 기법을 사용해 적절한 빈 인스턴스나 속성을 주입하는 “주입기(injector)” 자체에 대한 의존성을 요구할 수 있습니다. 또한, DI를 사용하면 의존성 구현체를 아주 쉽게 다른 구현체로 바꿀 수 있습니다. 예를 들어 PostgreSQL 데이터베이스를 사용해 데이터 작업을 수행하는 DAO 컴포넌트를 오라클을 사용하도록 변경한다고 가정해봅시다. DI를 사용하면 비즈니스 객체가 PostgreSQL 대신 오라클 구현체를 사용하도록 의존성을 간단히 재구성할 수 있습니다.

• 단일 저장소에서 공통 의존성을 관리: 데이터 소스 연결, 트랜잭션, 원격 서비스와 같은 공통 서비스의 의존성을 관리할 때, 기존 방식으로는 의존성이 필요한 인스턴스를 직접 생성하거나 팩터리 클래스를 통해 가져와야 합니다. 이렇게 하면 애플리케이션 내의 클래스 간에 의존성이 넓게 퍼져버리므로 이를 변경하기 어렵습니다. 하지만 DI를 사용하면 공통적인 의존성에 대한 정보가 모두 단일 저장소에 저장돼 의존성 관리가 훨씬 단순해지고 에러가 발생할 일도 그만큼 적어집니다.

• 테스트 편의성 향상: DI에 맞게 클래스를 설계하면 의존성을 쉽게 바꿀 수 있습니다. 이는 특히 애플리케이션을 테스트할 때 편리합니다. 예를 들어 복잡한 업무 처리를 수행하는 비즈니스 객체가 있다고 가정해 봅시다. 비즈니스 객체는 보통 DAO를 사용해 관계형 데이터베이스에 저장된 데이터에 접근합니다. 대부분은 DAO 자체를 테스트하기보다는 다양한 데이터를 이용해 비즈니스 객체를 테스트하는 데 관심이 있습니다. 기존 접근 방식에서는 비즈니스 객체가 DAO 인스턴스를 가져오는 책임을 가지고 있습니다. 따라서 이 DAO 구현체를 테스트 데이터 집합을 반환하는 목(mock) 구현체로 바꾸기 어려워서 테스트하기가 쉽지 않습니다. 그래서 테스트할 때 데이터베이스에 테스트를 위한 적절한 데이터가 있는지 확인하고 완전한 DAO 구현체를 사용해야 합니다. 만약 DI를 사용한다면 테스트용 데이터를 반환하는 DAO 목 구현체를 만들어 비즈니스 객체에 전달할 수 있습니다. 이러한 메커니즘은 애플리케이션의 모든 레이어를 테스트하는 데 활용할 수 있으며 특히 웹 컴포넌트를 테스트할 때 HttpServletRequest와 HttpServletResponse의 목 구현체를 만들어서 유용하게 사용할 수 있습니다.