봄 주석 기반 DI 대 xml 구성?

봄 주석 기반 DI 대 xml 구성?

최근 우리 팀에서는 스프링 의존성을 정의하기 위해 코드에 스프링 주석을 사용하는 것에 대해 논의하기 시작했습니다.현재 context.xml을 사용하여 종속성을 정의하고 있습니다.두 가지 방법 중 하나를 사용하는 것이 더 나은 경우에 대한 단서를 주시겠습니까?

편집: 이것이 더 일반적인 질문과 중복되는 질문으로 보인다는 것을 알지만, 저는 일반적인 질문과 다른 대답과 태도를 가질 것이라고 생각하는 의존성 주입에 대한 주석과 구성의 영향에 관심이 있습니다.

여기서 관련 게시물을 읽고 팀에서 추가적인 논의를 한 후 다음과 같은 결론에 도달합니다.저는 그것이 이곳의 다른 사람들에게 유용하기를 바랍니다.

XML 구성(지금까지 사용하고 있음)에 대해서는 라이브러리에서 정의한 종속성(당사에서 개발하든 타사에서 개발하든 상관없이)에 대해 XML 구성을 유지하기로 결정했습니다.
라이브러리는 정의상 특정 기능을 제공하며 DI를 포함하지 않는 다양한 시나리오에서 사용할 수 있습니다.따라서 우리가 직접 개발하는 라이브러리 프로젝트에서 주석을 사용하면 DI 프레임워크(우리의 경우 봄)와 라이브러리의 종속성을 생성하여 비 DI 컨텍스트에서 라이브러리를 사용할 수 없게 됩니다.추가 의존성을 갖는 것은 우리 팀(일반적으로 IMHO) 사이에서 좋은 관행으로 간주되지 않습니다.

응용프로그램을 조립할 때 응용프로그램 컨텍스트는 필요한 종속성을 정의합니다.이렇게 하면 응용 프로그램이 참조된 모든 구성 요소를 결합하는 중심 장치가 되므로 종속성 추적이 단순화되며, 일반적으로 여기서 모든 배선이 실제로 발생해야 합니다.

XML은 또한 많은 구성 요소를 사용할 응용 프로그램 모듈을 다시 컴파일하지 않고 모의 구현을 제공할 때 유용합니다.따라서 로컬 또는 프로덕션 환경에서 테스트할 때 유연성을 확보할 수 있습니다.

주석과 관련하여, 우리는 주입된 구성 요소가 변하지 않을 때(예를 들어, 응용 프로그램 전체에서 구성 요소에 대한 특정 구현만 사용될 때) 주석을 사용하는 데 도움이 될 수 있다고 결정했습니다.

주석은 한 번에 종속성의 다른 구현을 변경하거나 지원하지 않으며 다른 방식으로 구성될 가능성이 없는 작은 구성요소/응용프로그램에 매우 유용합니다(예: 다른 빌드에 다른 종속성 사용).단순한 마이크로 서비스가 이 범주에 포함될 것입니다.

주석으로 구성된 충분히 작은 구성요소는 XML 구성에서 해당 구성요소를 다룰 응용프로그램 없이 다른 프로젝트에서 즉시 사용할 수 있습니다.이렇게 하면 애플리케이션에 대한 애플리케이션 종속성 배선이 단순해지고 반복적인 설정이 줄어듭니다.

그러나 이러한 구성 요소는 전체 애플리케이션을 조립할 때 코드를 스크롤하거나 IDE에 모듈을 로드하지 않고도 이러한 종속성을 파악할 수 있도록 기술 문서에 잘 설명되어 있어야 한다는 데 동의했습니다.

주석 구성 구성 요소의 부정적인 부작용은 다른 구성 요소가 충돌 전이 종속성을 초래할 수 있으며, 충돌을 해결하는 것은 최종 응용 프로그램에 달려 있다는 것입니다.이러한 종속성이 XML에 정의되어 있지 않으면 충돌 해결 접근 방식이 상당히 제한적이며 가능한 경우 모범 사례와는 거리가 멀어집니다.따라서 주석을 사용할 때 구성 요소는 사용할 종속성에 대해 충분히 성숙해야 합니다.

일반적으로 시나리오에 따라 종속성이 다르거나 모듈을 다른 구성 요소와 함께 사용할 수 있는 경우 XML을 고수하기로 결정했습니다. 두 가지 접근 방식 사이에 균형이 맞아야 하며 사용 방법에 대한 명확한 아이디어가 있어야 합니다.

---

혼합 접근법에 대한 중요한 업데이트입니다.최근 QA 팀을 위해 만든 테스트 프레임워크에 대한 사례가 있었는데, 다른 프로젝트의 종속성이 필요했습니다.프레임워크는 주석 접근 방식과 Spring 구성 클래스를 사용하도록 설계되었으며 참조된 프로젝트에는 참조해야 할 xml 컨텍스트가 있습니다. 수업가 안깝게우시수험은업곳도(사던가했용리타우은곳)▁we▁used던▁(▁unfortun(사했where▁the▁testorg.testng스프링 지원 포함)은 xml 또는 java 구성 클래스에서만 작동할 수 있으며 둘 다 혼합할 수 없습니다.

이러한 상황은 접근 방식을 혼합하는 것이 충돌할 수 있으며, 접근 방식을 폐기해야 하는 경우를 보여줍니다.우리의 경우 테스트 프레임워크를 spring xml 컨텍스트를 사용하도록 마이그레이션했지만 다른 사용법은 그 반대를 의미할 수 있습니다.

XML 구성을 사용할 경우의 몇 가지 이점은 다음과 같습니다.

1. XML 구성은 주석이 있는 경우 소스 코드 전체에 분산되는 대신 한 곳에 있습니다.STS와 같은 IDE를 사용하면 모든 주석 기반 구성을 한 곳에서 볼 수 있다고 주장할 수도 있지만, 저는 IDE에 의존하는 것을 결코 좋아하지 않습니다.
2. XML 구성을 작성하는 데는 조금 더 많은 노력이 필요하지만 나중에 종속성을 검색하고 프로젝트를 이해하려고 하면 시간이 많이 절약됩니다.
3. XML은 구성을 잘 구성하고 단순하게 유지합니다.따라서 비교적 경험이 부족한 신입 팀원들이 신속하게 대처할 수 있도록 지원합니다.
4. 코드를 다시 컴파일하고 다시 배포할 필요 없이 구성을 변경할 수 있습니다.그래서 생산 지원에 관해서는 더 낫습니다.

즉, XML 구성에는 약간의 노력이 필요하지만 나중에 대규모 프로젝트에서 많은 시간과 문제를 줄일 수 있습니다.

2.5년 후:

우리는 요즘 주석을 주로 사용하지만, 가장 중요한 변화는 하나의 큰 프로젝트 대신 많은 작은 프로젝트를 만든다는 것입니다.따라서 의존성을 이해하는 것은 더 이상 문제가 되지 않습니다. 각 프로젝트는 고유한 목적과 상대적으로 작은 코드베이스를 가지고 있기 때문입니다.

제 경험으로 볼 때, 저는 XML과 주석 기반 DI의 조합을 사용하는 것을 선호합니다. 만약 제가 빈 안에 요소의 Map을 주입해야 한다면, 저는 util:map과 autowire를 정의해야 합니다. 또한, 여러 데이터 소스가 있는 경우 세션 팩토리에 데이터 소스를 주입하기 위해 XML DI를 사용해야 합니다.따라서 두 가지를 모두 조합해야 합니다.

서비스와 Dao를 자동 감지하기 위해 컴포넌트 스캔을 사용하는 것을 선호합니다.이렇게 하면 구성 요소 스캔으로 전환하여 구성 파일을 약 50% 줄일 수 있습니다.주석 기반 DI는 이름(@Resource)과 유형(@Autowired)을 모두 지원합니다.

간단히 말해서, 두 가지를 모두 고정하는 것이 제 조언입니다. 저는 앞으로 봄 출시될 때 더 많은 주석 지원이 반드시 카드에 실릴 것이라고 생각합니다.

다음 답변을 참조하십시오. Xml 구성 대 주석 기반 구성

여기서 직접 인용한 짧은 내용:

주석은 그 용도가 있지만 XML 구성을 제거하는 유일한 은총은 아닙니다.둘을 섞는 것을 추천합니다!

예를 들어, Spring을 사용하는 경우 응용프로그램의 종속성 주입 부분에 XML을 사용하는 것이 매우 직관적입니다.이는 코드의 종속성을 코드에서 멀어지게 하고, 반대로 종속성이 필요한 코드의 주석을 사용하여 코드가 이 자동 구성을 인식하도록 합니다.

그러나 트랜잭션 관리를 위해 XML을 사용하는 대신, 주석을 사용하여 메서드를 트랜잭션으로 표시하는 것은 프로그래머가 알고 싶어할 정보이기 때문에 매우 타당합니다.

편집: 또한 여기서 답을 살펴 보십시오. Java 종속성 주입: XML 또는 주석. 이들은 아마도 여러분이 관심을 갖는 분야를 훨씬 더 잘 목표로 삼을 것입니다.

제 경험상 xml 구성보다 주석이 더 낫습니다.어떤 경우에도 xmls를 오버라이드하고 주석을 사용할 수 있다고 생각합니다.또한 Spring 4는 우리에게 주석에 대한 엄청난 지원을 제공하며, 우리는 xml에서 주석 e.t.c로 보안을 재정의할 수 있으므로 100줄 xml이 아니라 10줄 Java Code가 될 것입니다.

주석이 XML보다 봄을 구성하는 데 더 나은가요?

주석 기반 구성의 도입으로 이 접근 방식이 XML보다 '더 나은' 것인지에 대한 의문이 제기되었습니다. 간단히 말해서, 이 접근 방식은 의존적입니다.긴 대답은 각 접근 방식에는 장단점이 있다는 것이며, 일반적으로 어떤 전략이 자신에게 더 적합한지 결정하는 것은 개발자에게 달려 있습니다.주석은 정의된 방식으로 인해 선언에 많은 컨텍스트를 제공하여 더 짧고 간결한 구성으로 이어집니다.그러나 XML은 다음과 같은 기능을 사용하지 않고 구성요소를 연결하는 데 탁월합니다.

소스 코드를 터치하거나 다시 컴파일할 수 있습니다.일부 개발자는 소스에 가까운 배선을 선호하는 반면, 주석이 달린 클래스는 더 이상 POJO가 아니며, 더 나아가 구성이 분산되어 제어하기 어려워진다고 주장합니다.

어떤 선택이든, Spring은 두 가지 스타일을 모두 수용할 수 있고 심지어 함께 혼합할 수도 있습니다.JavaConfig 옵션을 통해 Spring은 대상 구성 요소의 소스 코드를 건드리지 않고 비침습적인 방식으로 주석을 사용할 수 있으며 툴링 측면에서 모든 구성 스타일이 Spring Tool Suite에서 지원된다는 점에 주목할 필요가 있습니다.

제 개인적인 옵션은 xml이 더 낫다는 것입니다. 왜냐하면 당신은 모든 것을 한 곳에 가지고 있고 클래스를 검색하기 위해 패키지를 깊이 넣을 필요가 없기 때문입니다.

XML을 사용하면 프레임워크별 주석으로 인해 코드가 오염되어 원하지 않는 커플링이 생성되는 것을 방지할 수 있습니다.필요한 경우 언제든지 교체할 수 있도록 프레임워크를 응용프로그램 경계에 유지합니다.

프레임워크는 왔다가 사라지지만 많은 애플리케이션은 수십 년 동안 사용됩니다.다행히도 Spring은 비침습적 프레임워크이며 아키텍처를 굽히지 않습니다.구성을 XML로 유지하면 해당 구성이 응용 프로그램에서 훨씬 더 분리됩니다.

비고: 이 모든 이점을 누리려면 응용프로그램이 처음부터 잘 설계되어야 합니다.

어떤 방법이 좋은지는 당신의 프로젝트에 따라 다릅니다.우리는 xml이나 주석을 피할 수 없습니다.xml을 사용할 때의 한 가지 장점은 xml 컨텍스트 파일만 봐도 프로젝트 구조를 이해할 수 있지만 주석을 달면 메타 구성이 줄어듭니다.그래서 저는 30% xml과 70% 주석을 선호합니다.

언급URL : https://stackoverflow.com/questions/8428439/spring-annotation-based-di-vs-xml-configuration