[SPRING] Java Dependency Injection : XML 또는 주석

Java Dependency Injection : XML 또는 주석

인기가있는 특수 효과. Spring-3은이를 지원합니다. CDI는 그들에 크게 의존합니다 (주석이없는 CDI는 사용할 수 없습니다.)

내 질문은 왜?

몇 가지 문제를 들었습니다.

다른 문제가 있습니까?

그리고 이제 XML에 대한 나의 장점 :

XML 기반 DI를 사용하면 코드 작성을 명확하게 할 수 있습니다. 각 클래스는 주입에 대해 잘 모르기 때문에 어떤 식 으로든 구성하고 테스트 할 수 있습니다.

어떻게 생각해?

해결법

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

   1.나는 Guice와의 경험을 통해서만 이야기 할 수 있지만, 필자의 생각이다. 짧게는 주석 기반 구성을 사용하면 응용 프로그램을 연결하기 위해 작성해야하는 양이 크게 줄어들고 구성 파일 자체를 만지지 않고도 무엇을 ... 자주 사용하는지에 따라 쉽게 변경할 수 있습니다. 이것은 비교적 일반적인 경우를 다루기가 약간 어렵게 만드는 대신에 가장 일반적인 경우를 절대적으로 사소한 것으로 만드는 것입니다.

   나는 Guice와의 경험을 통해서만 이야기 할 수 있지만, 필자의 생각이다. 짧게는 주석 기반 구성을 사용하면 응용 프로그램을 연결하기 위해 작성해야하는 양이 크게 줄어들고 구성 파일 자체를 만지지 않고도 무엇을 ... 자주 사용하는지에 따라 쉽게 변경할 수 있습니다. 이것은 비교적 일반적인 경우를 다루기가 약간 어렵게 만드는 대신에 가장 일반적인 경우를 절대적으로 사소한 것으로 만드는 것입니다.

   나는 수업에 "주사에 대한 생각이 없다"라는 너무 독단적 인 문제가 있다고 생각한다. 클래스의 코드에서 주입 컨테이너에 대한 참조가 없어야합니다. 나는 그것에 절대적으로 동의한다. 그러나 주석은 코드가 아닙니다. 클래스 자체가 작동하는 방식에 대해서는 아무런 변화가 없습니다 ... 주석이있는 클래스의 인스턴스를 마치 전혀 존재하지 않는 것처럼 만들 수 있습니다. 따라서 DI 컨테이너를 완전히 사용하지 않고 주석을 그대로두면 아무런 문제가 없습니다.

   특정 클래스 (예 : 특수 효과)에 삽입에 대한 메타 데이터 힌트를 제공하지 않기로 선택하면 클래스에 필요한 종속성에 대한 유용한 정보 소스를 버리게됩니다. 그 정보를 다른 곳에서 (XML로 말하면) 반복하거나 예기치 않은 문제로 이어질 수있는 autowiring과 같은 신뢰할 수없는 마법에 의존해야합니다.

   특정 질문에 답변하려면 다음을 수행하십시오.

   많은 것들이 XML 설정에 좋지 않습니다.

   즉, 많은 사람들이 XML을 오랫동안 사용해 왔기 때문에 사람들이 마음이 바뀔 것으로는 기대하지 않는다고 확신합니다.

   응용 프로그램의 단일 구성 (예 : 프로덕션)에 대해 각 인터페이스의 구현은 종종 단 하나입니다. 요점은 애플리케이션을 시작할 때 일반적으로 인터페이스를 단일 구현에 바인딩하기 만하면된다는 것입니다. 그런 다음 다른 많은 구성 요소에서 사용할 수 있습니다. XML 구성을 사용하면 해당 인터페이스를 사용하는 모든 구성 요소에 해당 인터페이스 (또는 원하는 경우 "bean")의 특정 바인딩을 사용하도록 알릴 수 있습니다. 주석 기반 구성에서는 바인딩을 한 번 선언하면 다른 모든 요소는 자동으로 처리됩니다. 이는 매우 중요하며 작성해야하는 구성의 양을 크게 줄입니다. 또한 구성 요소에 새로운 종속성을 추가 할 때 구성에 대해 전혀 변경하지 않아도된다는 것을 의미합니다!

   일부 인터페이스에 대한 모의 구현이 없다는 것은 부적절합니다. 단위 테스트에서는 일반적으로 모의 객체를 만들고 직접 전달합니다 ... 설정과 관련이 없습니다. Mock을 사용하는 특정 인터페이스와의 통합 테스트를 위해 전체 시스템을 설정하면 ... 아무 것도 변경되지 않습니다. 시스템의 통합 테스트를 실행하는 경우 여전히 1 개의 구현 만 사용하고 있으므로 한 번만 구성하면됩니다.

   Guice에서 쉽게이 작업을 수행 할 수 있으며 CDI에서도 할 수 있다고 상상합니다. 따라서 주석 기반 구성 시스템을 사용하여이 작업을 수행하는 것이 절대적으로 금지 된 것처럼 아닙니다. 즉, 대다수의 응용 프로그램에서 주입 된 클래스의 대부분이 이미 없으면 @Inject를 추가 할 수있는 클래스라고 말할 수 있습니다. 어노테이션 (JSR-330)을위한 경량의 표준 Java 라이브러리가 존재하기 때문에 앞으로 더 많은 라이브러리와 프레임 워크가 @Inject 어노테이션 생성자를 구성 요소에 제공하는 것이 훨씬 쉬워집니다.

   한정어는 이것에 대한 하나의 해결책이며, 대부분의 경우 정당해야합니다. 그러나 어떤 경우에는 특정 주입 된 클래스의 매개 변수에서 한정자를 사용하면 작동하지 않는 무언가를하고 싶은 경우가 종종 있습니다. 클래스의 인스턴스를 여러 개 갖고 자 할 때 각각 다른 인터페이스 구현이나 인스턴스를 사용하기 때문입니다. Guice는 PrivateModules라는 이름으로이를 해결합니다. 나는 CDI가이 점에서 무엇을 제공하는지 모른다. 그러나 다시 한번, 이것은 소수에 속하는 사례이며 구성을 처리 할 수있는 한 나머지 구성을 고칠 가치가 없습니다.

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

   2.필자는 다음과 같은 원칙을 가지고 있습니다. 구성 관련 빈은 XML로 정의됩니다. 그 밖의 모든 것 - 주석이 있습니다.

   필자는 다음과 같은 원칙을 가지고 있습니다. 구성 관련 빈은 XML로 정의됩니다. 그 밖의 모든 것 - 주석이 있습니다.

   왜? 클래스에서 구성을 변경하지 않으려 고하기 때문입니다. 반면에 사용 가능하게하려는 클래스에 @Service 및 @Inject를 작성하는 것이 훨씬 간단합니다.

   이는 어떤 방식 으로든 테스트를 방해하지 않습니다. 주석은 컨테이너에서 파싱되는 메타 데이터 일뿐입니다. 원하는 경우 다른 종속성을 설정할 수 있습니다.

   CDI는 XML 구성을위한 확장 기능을 가지고 있지만 주석을 주로 사용합니다. 그것은 내가 특별히 좋아하지 않는 것입니다.

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

   3.내 의견으로는, 이것은 더 맛이 문제입니다.

   내 의견으로는, 이것은 더 맛이 문제입니다.

   1) 우리 프로젝트 (Spring 3 사용)에서 XML 구성 파일을 구성 (구성)하기를 원합니다. (최종 사용자 입장에서) 구성 할 필요가 없거나 다른 문제가 xml에서 강제로 수행되지 않는 경우 XML 정의에 빈 정의 / 배선을 넣지 말고 @Autowired를 사용하십시오 등.

   2) Spring을 사용하면 @Qualifier를 사용하여 여러 인터페이스가 존재하는 경우 인터페이스의 특정 구현과 일치시킬 수 있습니다. 네, 이것은 실제 구현체의 이름을 지정해야한다는 것을 의미합니다.

   우리의 경우 XML을 사용하여 모든 DI를 처리하면 XML 구성 파일이 많이 부풀어 오릅니다. 별도의 XML 파일 (또는 파일)로 처리 할 수는 있지만 유효하지는 않습니다. 앞에서 말했듯이 이것은 맛의 문제이며 주석을 통해 주입을 처리하는 것이 더 쉽고 깨끗하다고 ​​생각합니다 (XML 파일을 거치지 않고 클래스를보고 어떤 서비스 / 저장소 / 어떤 것이 사용되는지 확인할 수 있습니다). bean-declaration을 찾는다).

   편집 : 다음은 @Autowired와 XML에 대한 의견이 있습니다. Spring @Autowired usage

4. ==============================

   4.내가 지적한대로 코드를 분명하게 유지하는 것이 좋습니다. XML은 IOC 원칙에서 나에게 더 좋은 점을 제공합니다.

   내가 지적한대로 코드를 분명하게 유지하는 것이 좋습니다. XML은 IOC 원칙에서 나에게 더 좋은 점을 제공합니다.

   다시 말하지만, 그것은 단지 내 관점, 거기에 근본주의 :)

   편집 : 거기에 몇 가지 유용한 토론 :

5. ==============================

   5."하지만 xml에 나쁜 점이 있습니까?" 아직 관리해야 할 파일이면서 버그를 찾아야하는 또 다른 장소입니다. 특수 효과가 코드 바로 옆에 있으면 관리 및 디버그하는 것이 훨씬 쉽습니다.

   "하지만 xml에 나쁜 점이 있습니까?" 아직 관리해야 할 파일이면서 버그를 찾아야하는 또 다른 장소입니다. 특수 효과가 코드 바로 옆에 있으면 관리 및 디버그하는 것이 훨씬 쉽습니다.

6. ==============================

   6.모든 것들과 마찬가지로 의존성 주입은 적당히 사용해야합니다. 또한 주사의 모든 덫 치기는 응용 프로그램 코드와 분리되어 메인 코드와 관련된 코드로 이관되어야합니다.

   모든 것들과 마찬가지로 의존성 주입은 적당히 사용해야합니다. 또한 주사의 모든 덫 치기는 응용 프로그램 코드와 분리되어 메인 코드와 관련된 코드로 이관되어야합니다.

   일반적으로 응용 프로그램에는 추상 응용 프로그램 코드와 구체적인 구현 세부 사항을 구분하는 경계가 있어야합니다. 경계를 넘는 모든 소스 코드 종속성은 응용 프로그램을 가리켜 야합니다. 그 경계의 구체적인 측면, 즉 메인 파티션을 '메인'(또는 동등한 것)이 살아야하기 때문에 호출합니다.

   메인 파티션은 공장 구현, 전략 구현 등으로 구성됩니다. 그리고 경계선의 측면에서 의존성 주입 프레임 워크가 작업을 수행해야합니다. 그런 다음 주입 된 종속성을 정상적인 방법으로 경계를 넘어 응용 프로그램으로 전달할 수 있습니다. (예 : 논증).

   주입 된 종속성의 수는 상대적으로 작아야합니다. 12 개 이하. 이 경우 XML 또는 주석 사이의 결정은 중요하지 않습니다.

7. ==============================

   7.또한 Spring JavaConfig도 잊지 마십시오.

   또한 Spring JavaConfig도 잊지 마십시오.

8. ==============================

   8.필자의 경우 응용 프로그램을 작성하는 개발자는 다른 부서 (부서 / 기술) / 언어를 구성하는 개발자와 최종 그룹이 소스 코드에 액세스하지 못하는 경우가 있습니다 (많은 엔터프라이즈 설정의 경우). 개발자가 구성한 xml을 사용하는 대신 소스 코드를 공개해야하기 때문에 Guice를 사용할 수 없게됩니다.

   필자의 경우 응용 프로그램을 작성하는 개발자는 다른 부서 (부서 / 기술) / 언어를 구성하는 개발자와 최종 그룹이 소스 코드에 액세스하지 못하는 경우가 있습니다 (많은 엔터프라이즈 설정의 경우). 개발자가 구성한 xml을 사용하는 대신 소스 코드를 공개해야하기 때문에 Guice를 사용할 수 없게됩니다.

   전반적으로 나는 구성 요소를 제공하고 응용 프로그램을 구성 / 구성하는 것은 두 가지 다른 연습이며 필요한 경우 이러한 우려의 분리를 제공한다는 것을 인식하는 것이 중요하다고 생각합니다.

9. ==============================

   9.여기에 이미 추가 된 몇 가지 사항 만 있습니다.

   여기에 이미 추가 된 몇 가지 사항 만 있습니다.

10. ==============================

    10.XML은 응용 프로그램 코드 자체와 명확하게 구분 된 선언적 스타일의 유일한 이점이 있습니다. 그것은 DI 우려와 독립적입니다. 단점은 자세한 정보, 열악한 리팩터링 강건성 및 일반적인 런타임 오류 동작입니다. 예를 들어 IDE 지원과 비교할 때 거의 이점이없는 일반 (XML) 도구 지원이 있습니다. 자바. 이 XML 외에도 성능 오버 헤드가 있으므로 일반적으로 코드 솔루션보다 느립니다.

    XML은 응용 프로그램 코드 자체와 명확하게 구분 된 선언적 스타일의 유일한 이점이 있습니다. 그것은 DI 우려와 독립적입니다. 단점은 자세한 정보, 열악한 리팩터링 강건성 및 일반적인 런타임 오류 동작입니다. 예를 들어 IDE 지원과 비교할 때 거의 이점이없는 일반 (XML) 도구 지원이 있습니다. 자바. 이 XML 외에도 성능 오버 헤드가 있으므로 일반적으로 코드 솔루션보다 느립니다.

    어노테이션은 종종 애플리케이션 코드를 다시 고려할 때보다 직관적이고 강력하다고합니다. 또한 guice가 제공하는 IDE 지침이 도움이됩니다. 하지만 DI 코드와 애플리케이션 코드가 섞여있다. 응용 프로그램은 프레임 워크에 종속됩니다. 분명한 분리가 거의 불가능합니다. 다른 상황 (예 : 로봇 다리 문제)에 따라 같은 장소 (생성자, 필드)에서 다른 주입 동작을 설명 할 때 주석도 제한됩니다. 또한 그들은 자신의 소스와 같은 외부 클래스 (라이브러리 코드)를 처리 할 수 ​​없습니다. 따라서 XML보다 빠르게 실행되는 것으로 간주됩니다.

    두 기술 모두 심각한 단점이 있습니다. 따라서 Silk DI를 사용하는 것이 좋습니다. 코드에서 선언적으로 정의되었지만 (위대한 IDE 지원) 응용 프로그램 코드에서 100 % 분리되었습니다 (프레임 워크 의존성 없음). 소스 또는 외부 라이브러리의 모든 코드를 동일하게 취급 할 수 있습니다. 로봇 다리 문제와 같은 문제는 일반적인 바인딩으로 해결하기 쉽습니다. 또한 고객의 요구 사항에 맞도록 지원합니다.

from https://stackoverflow.com/questions/4995170/java-dependency-injection-xml-or-annotations by cc-by-sa and MIT license