[SPRING] Spring이 직접 필드 의존성 주입을 지원하지 않는 이유는 무엇입니까 (autowired를 제외하고)?

Spring이 직접 필드 의존성 주입을 지원하지 않는 이유는 무엇입니까 (autowired를 제외하고)?

직접 필드 종속성 주입에 관심이 있습니다. 전통적으로 Spring은 생성자 삽입 (생성자에 인수 제공)과 설정 기 기반 주입 (호출시 호출 호출자)을 모두 지원합니다.

그러나 Spring은 @Autowired를 사용하여 필드에 주석을다는 것으로 입증 된 바와 같이 직접 필드 주입 (setter 메서드없이 객체의 멤버 필드 설정)도 수행 할 수 있습니다. autowiring은 "beans"로만 제한되므로 원시 값은 주입 할 수 없습니다 ( "java.lang.String"클래스의 빈을 작성하면 다소 우회 할 수 있지만 이것은 작동하지만 autowiring의 일반적인주의 사항을가집니다). 이 스프링은 @Value를 지원하여 속성 등에서 멤버 필드에 직접 값을 설정한다.

그러나 Spring은 autowiring을하지 않고 속성을 멤버 필드에 직접 설정할 수 없다.

내 질문은 : 왜?

그것은 분명 그렇게 할 수 있습니다. 그렇다면 왜 그렇게하지 않습니까? 이것을 막는 큰 부정적인 부작용이 있습니까? 아니면 autowiring 만이 의미가 있도록 어떻게 든 제한된 기능입니까? 세터를 호출하는 것보다 더 큰 해킹이 필요합니까?

Spring이 이러한 선택을 한 이유에 대해서만 생각해 봅니다.

해결법

1. ==============================

   1.@Autowired 주석은 리플렉션을 사용하여 비공개 필드를 액세스 가능하게 만듭니다 (이 관련 질문 참조). Spring 구성 파일에서 사용되지 않는 이유는 세 가지입니다.

   @Autowired 주석은 리플렉션을 사용하여 비공개 필드를 액세스 가능하게 만듭니다 (이 관련 질문 참조). Spring 구성 파일에서 사용되지 않는 이유는 세 가지입니다.

2. ==============================

   2.내 스스로 대답을 찾은 것 같아. Spring 소스 코드로 가서 그 기능이 실제로 구현 된 방법을 보았다. 이것이 내가 찾은 것입니다 :

   내 스스로 대답을 찾은 것 같아. Spring 소스 코드로 가서 그 기능이 실제로 구현 된 방법을 보았다. 이것이 내가 찾은 것입니다 :

   XML을 통해 프로퍼티를 설정하는 것은 아마도 Spring의 가장 오래된 부분 일 것이고, 인트로 스펙 션, 프로퍼티 열거 (enumeration) 등을 위해 "java.beans"클래스에 매우 의존적이다. 그리고 분명히 필드 인트로 스펙 션을 전혀 지원하지 않는다. 이 위에는 속성 값이 문제의 속성에 적합한 값으로 변환 될 수있는 방법을 결정하는 유형 변환 메커니즘이 있습니다. 여기에는 깔끔하게 분리 할 수있는 조각이 없습니다.

   모든 @Autowired 등은 BeanPostProcessor에서 구현됩니다. BeanPostProcessor는 유형 변환과는 아무런 관련이없는 자체 유형 일치 메카니즘을 가지고 있습니다. 그래서 콩을 주입하는 이유이기도합니다. @Value에 대해서도 똑같은 점이 있습니다. 이것은 그 자리에서 해결되고 속성과는 아무런 관련이 없습니다.

   따라서 필드 주입 지원 기능을 추가하면 특히 코드의 부분이 거의 완전히 별개이므로 사소한 엔지니어링 노력이 아닙니다.

   이것은 왜 "왜?"라고 정확히 대답하지는 않지만, 스프링이 직접 들판 의존성 주입을 추가하지 않은 이유에 대해 제가 들었던 다른 설명들보다 더 설득력있는 설명이라고 생각합니다. 그들이 JavaBeans뿐만 아니라 기존 써드 파티 클래스의 구성을 허용하려는 점을 감안할 때, JavaBeans에 근본적인 무언가가 없다면 (나는 의심 스럽습니다.) 기능을 구현하기위한 엔지니어링 노력의 문제 일뿐입니다.

3. ==============================

   3.JSR-250 @Resource 주석 (Spring 3.0 이상)을 통해이를 지원합니다.

   JSR-250 @Resource 주석 (Spring 3.0 이상)을 통해이를 지원합니다.

   나는 개인적으로 setter injection에 이것을 선호하며 constructor injection을 고려할 때 이것과 혼합 된 감정을 가지고 있습니다. FWIW에 대해 생각해 보았던 고려 사항은 다음과 같습니다.

   1) 생성자 삽입은 빈 의존성 (pro)을 스스로 문서화하는 좋은 방법이지만, (a) 비공개 필드, (b) 생성자 인수, (c) 매개 변수에서 필드를 설정하는 생성자 코드 , (d) 빈 구성 (@Configuration 클래스 또는 xml 중 하나)의 추가 코드. 그것은 캡슐화의 순결을 위해 단지 DRY 위반이 많습니다. 나는 심지어 신경 쓰지 않습니다. 이것은 거의 캡슐화에 위배됩니다.하지만 JSR-250 주석을 존중하는 일부 주입 컨테이너에 크게 의존합니다 (다음 참조).

   2) JSR-250 호환 컨테이너에 대한 종속성을 작성합니다. 나는 이것에 대해 여러 가지 감정을 가지고있다. @Resource에 대해 처음 들어봤을 때 시스템을 테스트하기가 더 어려워 질 것이라고 말하면서 썼습니다. 그러나, 나는 어쨌든 내 테스트에서 봄을 사용하여 끝났다. 어쨌든 나는 모의 콩을 여전히 사용할 수 있습니다. 그래서 그것은 결코 정말로 문제가되지 않았습니다. 그리고 질문은 테스트의 범위를 벗어났습니다. 언제 실제로 이것을 재사용하고 싶습니까? 내 마음 속에서 컨테이너를 이용하도록 시스템을 설계한다면 포용하고 그것을 사용하십시오. 마른 위반은 실제로 컨테이너 내부를 달리지 않는 유연성이 가치가 있습니까? 최소한 JSR-250 주석을 사용하면 JEE6 환경에서 실행할 수 있고 원하는 것처럼 주입 할 수 있습니다.

   3) 컨테이너 외부에서 인스턴스를 생성하면 디버깅 시나리오가 그렇게 좋지 않을 수 있습니다. 즉, 좋은 대신 무효 포인터 예외가 발생합니다. 이는 절충안입니다. 나는 개인적으로 그게 끔찍하지 않다고 생각합니다 - 당신이 @Resource를 가진 줄에 NPE를 가져다 준다면 주입되지 않았다는 것을 빨리 알 수 있습니다.

from https://stackoverflow.com/questions/5433143/why-doesnt-spring-support-direct-field-dependency-injection-except-for-autowir by cc-by-sa and MIT license