본문 바로가기

Back-End/토비의 스프링3

7.6 스프링 3.1 DI & 7.7 정리

스프링 프레임워크가 나온지가 어느덧 8년이 되었다.

 

스프링 1.0에서 3.1까지 나오면서 완벽에 가까울 만큼 하위 호환성을 가지고 있다고 한다.

 

이는, 스프링에서 항상 얘기하는 DI 패턴을 스스로 잘 지켰기 때문이다.

 

스프링 3.1에 이르러서는

 

1. 핵심 로직을 담은 자바 코드

2. DI 프레임워크

3. DI를 위한 메타데이터로서의 자바 코드 ( 구버전 때 XML )

 

크게 이렇게 3가지로 구성 되어 있다.

컨텍스트 분리와 @Import

이전 예제까지는 DI 정보와 테스트를 수행하기 위해 만든 DI 정보가 하나의 파일 안에 혼재해 있다.

결국, 성격이 다른 코드 분리에 실패한 것이다.

 

이제 DI 정보를 분리해보자.

테스트에서 사용할 빈정보를 다른 클래스로 분리했으니 완벽한 코드일까?

 

빈의 내용을 보면 SQL 서비스용 빈과 같이 독립적인 모듈은 분리하는게 더 좋다.

 

@Import

SQL 서비스와 관련된 빈 설정은 별도 클래스로 분리하긴 했지만 애플리케이션이 동작할 때 항상 필요한 정보다. 그러므로 AppContext와 긴밀하게 연결해주는게 좋다.

프로파일 @Profile, @ActiveProfile

메일 전송과 같은 서비스는 production말고 개발 환경에서는 필요가 없다. 이럴 때는 설정을 어떻게 해야 할까?

 

즉, 실행 환경에 따라 어떤 빈 설정을 사용할지 지정해야 한다.

 

이대로 테스트 코드를 실행하면 잘 동작할까? 실행해보면 DummyMailSender 빈을 못찾는다고 나온다.

 

왜냐하면 현재 컨테이너의 active 프로파일 목록을 설정하지 않았기 때문이다.

 

@Enable* 어노테이션

스프링 3.1에서는 @Import 를 다른 어노테이션으로 대체할 수 있는 방법을 제공한다.

 

@Componet를 확장하여 사용하는 이유

1. 자등등록 되는 빈의 종류나 계층이 무엇인지 나타낼 수 있음

2. AOP를 이용해 특정 어노테이션이 달린 빈만 선정해 부가 기능을 제공하게 만들 수 있음

가 있듯이

@Import도 다른 이름의 어노테이션으로 대체 가능하다.

 

 

정리

스프링 사용자라면 객체지향적인 설계와 DI를 효과적으로 활용하는 방법에 익숙해야 한다.

 

스프링이 제공해주지 않는 기능을 직접 구현할 때도 적극적으로 DI와 서비스 추상화, AOP 등을 활용할 수 있어야 한다.