Autowiring은 프로젝트 전반에 걸쳐 일관성 있게 사용될 때 가장 좋다. 만약 일반적으로 autowiring이 사용되지 않는 경우라면, 개발자는 한 두개의 bean을 wire하기 위해 autowiring을 사용하는 것을 주저할 것이다.
autowiring에 대한 다음 한계와 단점을 고려해보자.
- 'property'와 'constructor-arg' 세팅의 명확한 의존성들은 언제나 autowiring을 오버라이드한다. 또한 'simple properties'들은 autowire할 수 없다. 예를 들어 원시타입, 문자열, 클래스 그리고 simple properties를 포함하는 배열 등이 해당된다. 이러한 한계는 의도적인 것이다.
- Autowiring은 명확한 wiring보다는 덜 정확하다. 앞선 테이블에서 언급했지만, 스프링은 의도치 않은 결과를 낳을 수 있는 애매함들에 대해 판단하는 것을 피한다. 그러면 스프링의 관리 대상인 객체들 사이의 관계는 더이상 명확하게 기록되지 않게 된다.
- 스프링 컨테이너에서 문서를 만들어내는 도구들이 wiring 정보를 사용하지 못할 수도 있다.
- 컨테이너의 여러 bean들이 setter 메서드나 생성자 매개변수로 설정된 타입과 매치를 시도할 수 있다. 배열, 컬렉션 또는 맵 인스턴스들에게는 이것이 문제가 되지 않는다. 하지만 하나의 값이 기대되는 의존성들에게는 이 애매함이 해결되지 않는다. 만약 사용가능한 bean이 유일하지 않다면 예외가 발생할 것이다.
나중의 경우에는 몇 가지 대책이 있다.
- 명확한 wiring을 위해 autowiring을 포기한다.
- 다음 파트에서 논의하겠지만, 'autowire-candidate' 속성을 false로 세팅함으로써 특정 bean의 autowiring을 피하면 된다.
- <bean/> 요소의 'primary' 속성을 true로 세팅해서 단일한 bean 정의를 최우선의 후보가 될 수 있도록 설계한다.
- 어노테이션 기반의 컨테이너 설정에서 설명하듯이, 어노테이션 기반의 설정을 통해 더 잘 정제된 제어를 하면 된다.
'SpringFramework Core - I. IoC 컨테이너 > 4. 의존성' 카테고리의 다른 글
4.6. 메서드 주입 (0) | 2020.03.18 |
---|---|
4.5.2. Autowiring으로부터 bean 제외시키기 (0) | 2020.03.18 |
4.5. 협력자들 Autowiring하기 (0) | 2020.03.18 |
4.4. Lazy-initialized Beans (0) | 2020.03.18 |
4.3. depends-on 사용하기 (0) | 2020.03.18 |