봄 @ 자동 유선 사용법

사용의 장단점은 무엇입니까 Spring에 의해 연결되는 클래스에서 @Autowired ?

명확히하기 위해, 나는 특별히 XML에서 자동 배선이 아닌 @Autowired 주석 있습니다.

나는 아마 그것을 이해하지 못하지만, 나에게는 거의 반 패턴처럼 보입니다. 여러분의 클래스는 POJO가 아닌 DI 프레임 워크에 묶여 있음을 인식하기 시작합니다. 어쩌면 나는 처벌을위한 열성이지만 콩에 대한 외부 XML 구성을 좋아하고 명확한 배선을 좋아하므로 어디에 무엇이 배선되어 있는지 정확하게 알고 있습니다.

오랫동안 우리 모두가 사용했던 xml 파일과 같은 "중앙 집중식, 선언적 구성"을 갖는 가치가 있다고 믿었습니다. 그런 다음 파일의 대부분의 구성이 구성 되지 않았다는 것을 깨달았 습니다. 개발 후에도 변경되지 않았습니다. 그런 다음 "중앙 집중식"은 아주 작은 시스템에서만 가치가 있다는 것을 깨달았습니다. 작은 시스템에서만 구성 파일 을 전체적으로 파악할 수있을 것 입니다. 그리고 동일한 "배선"이 코드의 의존성에 의해 대부분 복제 될 때 실제로 배선 전체를 이해하는 가치는 무엇입니까? 따라서 내가 유지 한 유일한 것은 메타 데이터 (주석)이며, 이는 여전히 일종의 선언입니다. 이것들 은 런타임에 절대 변하지 않으며 결코 변하지 않습니다. 누군가가 즉시 변경하는 "구성"데이터-코드에 보관하는 것이 좋습니다.

가능한 한 완전 자동 배선을 사용합니다. 나는 그것을 좋아한다. 나는 총구를 위협하지 않는 한 구식 봄으로 돌아 가지 않을 것입니다. 완전히 선호하는 나의 이유는 @Autowired시간이 지남에 따라 변했다.

지금은 자동 배선을 사용하는 가장 중요한 이유는 시스템에서 추적해야 할 추상화가 적기 때문이라고 생각합니다. "콩 이름"은 사실상 사라졌습니다. 빈 이름은 xml 때문에 존재한다는 것이 밝혀졌습니다. 따라서 추상 간접의 전체 레이어 (bean-name "foo"를 bean "bar"에 연결)가 사라졌습니다. 이제 "Foo"인터페이스를 빈에 직접 연결하고 런타임 프로파일로 구현을 선택합니다. 이를 통해 종속성 및 구현을 추적 할 때 코드 로 작업 할 수 있습니다 . 내 코드에서 자동 유선 종속성을 볼 때 IDE에서 "구현으로 이동"키를 누르면 알려진 구현 목록이 나타납니다. 대부분의 경우 구현이 하나만 있으며 클래스에 직접 접근합니다. 할 수있다' 어떤 구현이 사용되고 있는지 (XML 배선을 사용하면 그 반대가 진실에 더 가깝다고 주장합니다.

이제 매우 단순한 계층이라고 말할 수 있지만 시스템에 추가하는 각 추상화 계층은 복잡성을 증가시킵니다 . 나는 XML이 내가 작업 한 시스템에 실제 가치를 더했다고 생각하지 않는다.

지금까지 작업 한 대부분의 시스템 에는 프로덕션 런타임 환경 이 하나만 구성되어 있습니다. 테스트 등을위한 다른 구성이있을 수 있습니다.

풀 오토와 이어링은 스프링의 루비 온 레일 (Ruby-on-rails of Spring)이라고 말하고 싶습니다. 대부분의 사용 사례가 따르는 일반적이고 일반적인 사용 패턴이 있다는 개념을 수용합니다. XML 구성하면 허용 / 구성되지 않을 수 일치 / 불일치 구성 사용을 많이. 불일치로 인해 너무 많은 XML 구성이 사용되는 것을 보았습니다. 코드와 함께 리팩터링됩니까? 생각하지 않았다. 그 이유는 무엇입니까? 보통은 아닙니다.

우리는 구성에서 한정자를 거의 사용하지 않으며 이러한 상황을 해결하는 다른 방법을 찾았습니다. 이는 우리가 직면 한 명백한 "불이익"입니다. 자동 배선과의 원활한 상호 작용을 위해 코딩 방식을 약간 변경했습니다. 고객 리포지토리는 더 이상 일반 Repository<Customer>인터페이스를 구현하지 않지만 CustomerRepository확장 되는 인터페이스 를 만듭니다 Repository<Customer>. 서브 클래 싱과 관련하여 간혹 트릭이있을 수도 있습니다. 그러나 일반적으로 더 강력한 타이핑 방향을 지시합니다. 거의 항상 더 나은 솔루션이라고 생각합니다.

그러나 그렇습니다. 대부분 봄이하는 특정 스타일의 DI와 관련이 있습니다. 우리는 심지어 우리는 여전히 우리의 시스템에서 일부 XML을 (우리가하고있는 캡슐화 / 정보 숨어 부서에서 일 주장 할 수 그래서),하지만 XML은 기본적으로 더 이상 종속성을 공개 세터를하지 않는 유일한 이상 현상을 포함한다. 완전 자동 배선은 XML과 잘 통합됩니다.

우리가 지금해야 할 유일한 것은입니다 @Component, @Autowired나머지는 (같은 JSR에 포함되는 JSR-250 우리가 스프링에 묶을 필요가 없습니다). 이것은 과거에 일어났던 방식 (물건이 java.util.concurrent떠오를 것)이므로, 다시 이런 일 이 일어나더라도 전혀 놀라지 않을 것입니다.

나를 위해 여기 스프링과 자동 배선에 대해 내가 좋아하거나 싫어하는 것이 있습니다.

장점 :

• 자동 배선은 불쾌한 XML 구성을 제거합니다.
• 필드, 세터 메소드 또는 생성자를 사용하여 직접 주입 할 수있는 주석을 사용하는 것이 훨씬 쉽습니다. 또한 주입 된 콩에 주석을 달고 '자격을 부여'할 수 있습니다.

단점 :

• 자동 배선 및 주석을 사용하면 XML 구성과 마찬가지로 Spring을 사용하거나 사용하지 않고 실행할 수있는 Spring 라이브러리에 의존 할 수 있습니다. 당신이 말했듯이, 당신은 DI 프레임 워크에 묶여 있습니다.
• 동시에 나는 콩을 '자격을 갖춘'것이 좋아서 나에게 코드가 정말 지저분 해집니다. 여러 장소에 같은 콩을 주입 해야하는 경우 동일한 문자열 이름이 반복되는 것을 보았습니다. 나에게 이것은 오류 가능성이있는 것 같습니다.

우리는 어쨌든 스프링 통합에 너무 의존하여 종속성 문제가 무의미하기 때문에 거의 독점적으로 직장에서 자동 배선을 사용하기 시작했습니다. 나는 자동 배선을 광범위하게 사용하는 Spring MVC 프로젝트에서 일했고 내 머리를 감싸기가 조금 어려웠습니다.

저는 자동 배선이 습득 된 취향이라고 생각합니다. 일단 익숙해지면 XML 구성보다 작업이 얼마나 강력하고 쉬우 며 두통이 훨씬 적다는 것을 알 수 있습니다.

우리는 큰 프로젝트에서 @Autowire에서 XML 구성으로 다시 전환하고 있습니다. 문제는 부트 스트랩 성능이 매우 낮다는 것입니다. 자동 배선 스캐너는 자동 배선 검색 클래스 경로에서 모든 클래스를로드하므로 Spring 초기화 중에 많은 클래스가 열심히로드됩니다.

스위칭 환경에 대한 논의는 거의 없었습니다. 내가 작업 한 대부분의 프로젝트는 작업중 인 환경에 따라 종속성을 주입하는 실제 문제였습니다. xml 구성을 사용하면 Spring EL을 사용하여 매우 간단하며 주석이있는 멋진 솔루션을 알지 못합니다. 방금 하나를 알아 냈습니다.

    @Value("#{${env} == "production" ? realService : dummyService}")
    private SomeService service;

작동해야하지만 좋은 해결책은 아닙니다.

@Autowire로 전환했습니다. 작은 프로젝트가 아닌 다른 곳에서 XML 구성을 유지하는 것은 그 자체의 과제가되었으며 이해력이 빠르게 저하되었습니다.

IntelliJ는 Spring 주석을 완벽하게 지원합니다.

이 주제에 대한 나의 취지는 XML 구성이 특히 대형 시스템에서 코드의 선명도를 감소 시킨다는 것입니다.

@Component와 같은 주석은 상황을 더욱 악화시킵니다. 기본 생성자를 제공해야하므로 종속성을 더 이상 최종적으로 만들 수 없으므로 개발자가 객체를 변경 가능하게 만듭니다. 종속성은 공용 setter를 통해 주입되거나 @Autowired를 통해 제어되지 않아야합니다. [종속성을 인스턴스화하는 클래스로 인해 종속성 주입이 더 나빠지더라도 새로 작성된 코드에서 여전히 볼 수 있습니다!]. 통제되지 않는 것은 큰 시스템에서 유형의 여러 구현 (또는 자식)을 사용할 수있을 때 @Autowired 구현을 이해하는 데 훨씬 더 관여합니다. 또한 테스트 환경에 대한 프로파일과 프로덕션에 대한 프로파일이 있다고 가정합니다.

구성 클래스를 선언하는 중간 지점을 고수합니다 (@Configuration을 사용하는 Java 기반 Spring 구성)

구성 클래스에서 모든 Bean을 명시 적으로 선언합니다. 구성 클래스에서만 @Autowired를 사용합니다. 목적은 Spring에 대한 종속성을 구성 클래스로 제한하는 것입니다.

@Configuration은 특정 패키지에 상주합니다. 스프링 스캔이 실행되는 유일한 곳입니다. (대규모 프로젝트에서 시작 시간을 크게 단축시킵니다)

나는 모든 클래스, 특히 데이터 객체, JPA, Hibernate 및 Spring을 불변으로 만들기 위해 노력하고 있으며 많은 직렬화 라이브러리가 이것을 손상시키는 것처럼 보입니다. 나는 세터를 제공하도록 강요하거나 재산 신고서에서 최종 키워드를 제거하는 것을 멀리합니다.

객체가 생성 된 후 변경 될 가능성을 줄이면 대규모 시스템의 버그를 크게 줄이고 버그가있는 경우 버그를 찾는 시간을 줄일 수 있습니다.

또한 개발자가 시스템의 다른 부분 사이의 상호 작용을 더 잘 설계하도록 강요하는 것 같습니다. 문제와 버그가 점점 더 많은 컴파일 오류가되어 낭비되는 시간을 줄이고 생산성을 향상시킵니다.

다음은 경험이 풍부한
전문가들입니다.

• @Autowire 주석을 사용할 수 있기 때문에 구성하기가 더 쉽습니다.
• setter 메소드를 사용하고 싶지 않으므로 클래스가 더 깨끗합니다.

단점

• DI를 사용하는 경우에도 XML 파일에 단단히 연결
• 구현을 찾기가 어렵습니다 (그러나 intellij와 같은 좋은 아이디어를 사용한다면 이것을 제거 할 수 있습니다)

개인적인 경험으로 나는 테스트 사례에서 @AutoWire 주석을 많이 사용하지 않았습니다.

XML 대신 주석으로 작성하는 것을 정말 좋아합니다. Spring 매뉴얼과 마지막 버전에 따르면 XML과 Annotation은 동일한 결과를 달성했습니다.

이것은 내 목록입니다

찬성:

• XML에서 쓸모없는 줄 제거
• 코드 디버깅 간소화 : 클래스를 열면 클래스에있는 내용을 읽을 수 있습니다.
• 400 개 이상의 XML 행을 가진 프로젝트를보다 빠르게 개발할 수 있습니까?

단점 :

• 표준 Java 구현은 아니지만 Java 표준 API 인 @Inject를 사용하도록 전환 할 수 있으므로 Bean은 Pojo로 유지됩니다.
• 당신은 단순히 모든 곳에서 db 연결 e를 사용할 수는 없지만 단지 의견 일뿐입니다. 모든 구성을 읽을 수있는 곳이 좋습니다.

내 이해를 위해 @Autowired는 인터페이스 참조를 참조하고 재정의 기능을 사용하는 동안 사용하는 것이 가장 좋지만 런타임에 때로는 null로 할당된다는 문제가 있습니다.