[SPRING] Java EE에서 CDI를 사용해야하는 이유

Java EE에서 CDI를 사용해야하는 이유

Java EE에서 CDI를 사용하는 방법을 설명하는 많은 기사가 있지만 실제로 어떤 이점이 있는지 알아내는 데 어려움이 있습니다. 예를 들어, 현재 Foo 인스턴스를 사용하는 클래스가 있다고 가정합니다. 나도 할 수있어.

Foo myFoo = new Foo();

또는

// Better, FooFactory might return a mock object for testing    
Foo myFoo = FooFactory.getFoo();

나는 내가 할 수있는 CDI로 그것을 계속 읽는다.

@Inject
Foo myFoo;

하지만 이전의 공장 기반 접근 방식보다이 점이 더 좋은 이유는 무엇입니까? 내가 알고있는 다른 유스 케이스가 있다고 가정하고 있지만이를 식별 할 수는 없습니다.

아래의 응답을 이해했다면 개념은 DI 프레임 워크가 중앙에서 구성된 마스터 객체 팩토리로 작동한다는 것입니다. 이것은 합리적인 해석인가?

최신 정보

나는 봄을 배우기 시작한 이래로 이제는 훨씬 더 의미가 있습니다. 아래 단락은 AccountDao 인스턴스를 사용하는 AccountService 클래스의 예제를 사용하는 Spring in Practice에서 가져온 것입니다. 긴 인용문에 사과드립니다.하지만 실제로 주입 된 리소스가 표준 초기화보다 더 중요한 이유를 알게되었습니다.

새 키워드를 사용하여 AccountService를 구성 할 수는 있지만 서비스 계층 개체를 만드는 것은 그리 간단하지 않습니다. 그들은 종종 DAO, 메일 발신자, SOAP 프록시 및 기타 등등에 의존합니다. AccountService 생성자에서 (또는 정적 초기화를 통해) 프로그래밍 방식으로 이러한 종속성을 각각 인스턴스화 할 수 있지만, 이러한 종속성은 스왑 된대로 종속성과 계단식 변경으로 이어집니다.

또한 외부에서 종속성을 만들고 setter 메서드 또는 생성자 인수를 통해 AccountService에 종속성을 설정할 수 있습니다. 이렇게하면 (내부적으로 AccountService에서 선언 된 한) 내부 종속성이 제거되지만 모든 곳에서 초기화 코드가 중복 될 수 있습니다. DAO를 작성하고 연결하는 방법은 다음과 같습니다. SpringService에 대한 귀하의 AccountService까지 :

<bean id="accountDao" class="com.springinpractice.ch01.dao.jdbc.JdbcAccountDao"/>

<bean id="accountService"
    class="com.springinpractice.ch01.service.AccountService">
    <property name="accountDao" ref="accountDao"/>
</bean>

위와 같이 빈을 설정하면 프로그램은 Spring ApplicationContext로부터 AccountService의 인스턴스를 요청할 수 있고 Spring DI 프레임 워크는 인스턴스화가 필요한 모든 것을 인스턴스화한다.

해결법

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

   1.CDI를 작성한 사람들은 당신에게 하나의 큰 객체 팩토리를주었습니다. 그들은 당신보다 더 잘 당신을 위해 일했습니다. XML 구성 또는 주석 중심이므로 모든 것을 코드에 포함 할 필요가 없습니다.

   CDI를 작성한 사람들은 당신에게 하나의 큰 객체 팩토리를주었습니다. 그들은 당신보다 더 잘 당신을 위해 일했습니다. XML 구성 또는 주석 중심이므로 모든 것을 코드에 포함 할 필요가 없습니다.

   Spring과 같은 Dependency Injection Engine은 공장보다 훨씬 많은 작업을 수행합니다. 제공하는 모든 것을 복제하기 위해서는 하나 이상의 팩토리 클래스와 한 줄의 코드가 필요합니다.

   물론 그것을 사용하지 않아도됩니다. 당신은 언제나 자유롭게 자신의 바퀴를 발명 할 수 있습니다. 그리고 바퀴를 만들거나 종속성을 제거하는 방법을 배우는 것이 목적이라면 -해야합니다.

   그러나 응용 프로그램을 개발하고 싶다면 다른 사람이 제공하는 도구를 사용하면 이점을 얻을 수 있습니다.

   의존성 주입에 대한 기사는 Martin Fowler에 의해 작성되었습니다. 나는 그것을 읽는 것이 좋습니다. 8 년 후 아직도 훌륭합니다.

   다음은 몇 가지 장점입니다.

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

   2.의존성 주입을 사용하는 목적은 주입 된 것을 사용하는 코드가 팩토리에 의존하지 않도록하기 위해서입니다. 팩토리 코드 예제에서는 코드에 임베드 된 정적 메서드 호출이 DI 접근법에서 필요하지 않습니다.

   의존성 주입을 사용하는 목적은 주입 된 것을 사용하는 코드가 팩토리에 의존하지 않도록하기 위해서입니다. 팩토리 코드 예제에서는 코드에 임베드 된 정적 메서드 호출이 DI 접근법에서 필요하지 않습니다.

   myFoo로 주입되는 것은 공장에 대해 알 필요가 없어야합니다.

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

   3.이것은 엔터프라이즈 프로그래밍이 무엇에 관한 것인지에 대한 중요하고 미묘한 질문입니다.

   이것은 엔터프라이즈 프로그래밍이 무엇에 관한 것인지에 대한 중요하고 미묘한 질문입니다.

   이름은 컨텍스트와 의존성을 고려하여 적절하게 선택됩니다.

   CDI는 더 우수하거나 더 깨끗한 코드와는 아무 관련이 없습니다. 복잡한 조직의 분산 소프트웨어 시스템을 구축하고 데이터를 공유 할 수 있도록 보장하는 것입니다. 정부 나 다른 관료 기관이 제어하는 ​​모든 소프트웨어에 대해 자체적으로 잘 문서화 된 패키지를 무분별하게 배포 할 수 있는지 100 % 확신하는 것입니다. 요즘에는 거의 모든 POJO를 주입 할 수 있습니다.

   어떤 종류의 클라이언트 응용 프로그램을 만들고 있다고 가정하고 모서리에있는 사용자의 이름을 인쇄하려고합니다.

   대부분의 JSR에는 아마도 "EA가 할 수 있기를 바라면 ..."어딘가에 묻혀있을 것입니다.

   CDI는 큰 (임의?) 수평 및 수직 비율의 응용 프로그램이 컨텍스트, 종속성 및 따라서 데이터를 공유 할 수 있기 때문에 선호됩니다.

   파울러의 말 :

   요컨대, 복잡한 엔터프라이즈 응용 프로그램의 중앙 집중식 "명령 및 제어"를 허용합니다. Java EE는 체계화되고 안정적인 추상화 프로세스이며 CDI는 매우 잘 작동하는 화신이며 거의 보이지 않게 만듭니다. 그것은 복잡한 애플 리케이션의 바느질은 거의 사소한 있습니다.

   두 가지 더 :

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

   4.높은 수준에서 CompSci의 대부분과 마찬가지로 Foo myFoo = new Foo ();와 같이 응용 프로그램에서 하드 코딩 된 간접 참조 (또는 추상화) 수준을 제공합니다. 이러한 간접 접근은 느슨하게 결합 된 코드를 가져오고, 이는 모듈 방식으로 이루어 지므로 더 간단한 방법으로 클래스 나 하위 시스템을 쉽게 교체, 서비스, 테스트 할 수 있습니다.

   높은 수준에서 CompSci의 대부분과 마찬가지로 Foo myFoo = new Foo ();와 같이 응용 프로그램에서 하드 코딩 된 간접 참조 (또는 추상화) 수준을 제공합니다. 이러한 간접 접근은 느슨하게 결합 된 코드를 가져오고, 이는 모듈 방식으로 이루어 지므로 더 간단한 방법으로 클래스 나 하위 시스템을 쉽게 교체, 서비스, 테스트 할 수 있습니다.

   간접 / 추상화를위한 많은 디자인과 패턴이 있습니다. 의존성 삽입은 단지 하나입니다.

   귀하의 질문 중 다른 측면은 "왜 CDI인가?"입니다. - 글쎄요, 누군가가 이미 당신을 위해 일을했기 때문입니다. 자신 만의 물건을 만들 수는 있지만 시간과 예산에 따라 수행해야하는 실제 시스템을 만드는 것이 목표라면 일반적으로 시간 낭비입니다. 미쉐린 (Michelin)의 별표를 붙인 주방장이 식료품과 요리를 할 때 기꺼이 도와 줄 이유가 무엇입니까?

from https://stackoverflow.com/questions/13047807/why-use-cdi-in-java-ee by cc-by-sa and MIT license