[Spring] DI(의존성 주입): 왜 필요하고 어떻게 사용할까?

 

스프링 프레임워크(Spring Framework)의 가장 중요한 개념 중 하나는 DI(Dependency Injection, 의존성 주입)입니다. DI를 이해하면 보다 유연하고 유지보수하기 쉬운 애플리케이션을 만들 수 있습니다. 이번 글에서는 DI가 무엇인지, 왜 필요한지, 그리고 스프링에서 DI를 구현하는 방법을 알아보겠습니다!

 

---

1. 의존성(Dependency)이란?

하나의 객체가 다른 객체를 필요로 하는 관계를 뜻합니다.

즉, 하나의 객체가 동작하기 위해 다른 객체를 사용합니다.

 

저는 앞으로 의존과 사용을 동일한 의미로 언급하도록 하겠습니다! (feat. 송아쌤)

 

 

예제를 보자면,

public class ProductController {
    private ProductService productService = new ProductService();
    
    public String findProductName(){
    	productService.findProductName();
    }
}

위처럼 ProductController에서 ProductService를 직접 생성(new ProductService())하고 있습니다.

클래스 내부에서 객체를 직접 생성하는 것은 강한 결합(Tight Coupling)에 해당합니다.

 

즉, ProductController 클래스는 ProductService 클래스를 사용(=의존)하며, ProductService가 없다면 ProductController도 정상으로 작동할 수 없습니다.

 

이러한 의존도를 낮추기 위해 스프링에서는 DI(의존성 주입)라는 개념을 사용하게 됩니다!

 

 

 

 

2. DI(의존성 주입)란?

객체가 필요로 하는 의존성을 직접 생성하지 않고 외부에서 주입받도록 하는 개념입니다.

이를 통해 클래스 간 결합도를 낮추고 코드의 유지보수를 용이하게 할 수 있습니다.

 

 

위의 예제를 DI 방식으로 수정해 보겠습니다.

public class ProductController {
    private final ProductService productService;
    
    // 생성자 주입 방식
    public ProductController(ProductService productService){
    	this.productService = proudctService;
    }
    
    public String findProductName(){
    	productService.findProductName();
    }
}

ProductController는 이전처럼 productService를 직접 생성하지 않고, 외부에서 생성자를 통해 주입받기 때문에 결합도가 낮아집니다. 

또한, DI를 통해 IoC를 실현하므로 객체 라이프 사이클을 스프링 컨테이너가 효율적으로 관리할 수 있습니다.

(+ 스프링의 싱글톤 패턴을 통해 객체 재사용도 가능)

 

 

ProductService(interface)에 속하는 객체(ProductAService, ProductBService)가 여러 가지라면,

DI를 적용하기 전의 방법에서는 이를 ProductController가 직접 어떤 객체로 만들지 선택해야 하고

DI를 적용한 후에는 구체적인 구현체가 아닌 ProductService에만 의존하게 됩니다.

 

 

 

 

 

그럼 이런 의존성을 주입하는 방법에는 어떠한 것들이 있는지 알아보겠습니다.

 

 

3. DI(의존성 주입) 방법 3가지

 

Setter Injection(setter 주입)

Setter 메서드를 통해 의존성을 주입하는 방법입니다.

@Controller
public class ProductController {
    private ProductService productService;
    
    //setter 주입
    @Autowired
    public void setProductService(ProductService productService){
    	this.productService = proudctService;
    }
    
    public String findProductName(){
    	productService.findProductName();
    }
}

 

ProductController가 생성된 후 setter를 통해 ProductService를 주입받는다. (=final 불가)

setter가 public 권한이기에 어디서든 setter를 호출하여 ProductService를 변경 가능하다.

또한, 필수 의존성이 휴먼에러로 주입되지 않을 수 있다.

 

 

 

 

Field Injection(필드 주입) - 지양😢

setter 주입의 단점을 보완하기 위해 필드에 직접 @Autowired를 적용하는 방식이 생겨났습니다.

@Controller
public class ProductController {

    @Autowired
    private ProductService productService;
    
    public String findProductName(){
    	productService.findProductName();
    }
}

3가지 방법 중 가장 간결하지만, 클래스 외부에서 접근이 불가능하여 테스트가 어렵다.

다른 방법들은 DI 프레임워크가 없더라도 정상 작동이 가능하나, 해당 방법은 DI 프레임워크의 도움 없이는 사용이 불가하다.

TDD가 보편화됨에 따라 해당 방법은 지양된다.

 

 

 

 

Constructor Injection(생성자 주입) - 권장👍

@Controller
public class ProductController {
    private final ProductService productService;
    
    @Autowired
    public ProductController(ProductService productService){
    	this.productService = productService;
	}
    
    public String findProductName(){
    	productService.findProductName();
    }
}

 

final 키워드와 함께 사용하여 불변성을 유지할 수 있다. (대부분의 의존 관계는 실행 후 종료까지 변하지 않는다.)

순수 자바 코드와 가장 비슷한 코드로 객체 지향의 특징이 잘 나타난다.

필수 의존성을 강제할 수 있기 때문에 휴먼 에러의 가능성이 낮다.

 

 

스프링 프레임워크 공식 문서에서도 Constructor Injection 방식을 가장 권장하고 있습니다.

더 자세한 내용이 궁금하신 분은 공식 문서를 참고하시길..!!

 

 

 

 

 

https://docs.spring.io/spring-framework/reference/core/beans/dependencies/factory-collaborators.html#beans-constructor-injection

Dependency Injection :: Spring Framework

 

 

 

그럼 안녕... ~