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

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

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

Foo myFoo = new Foo();

또는

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

CDI를 사용하면 다음을 수행할 수 있습니다.

@Inject
Foo myFoo;

하지만 이것이 이전의 공장 기반 접근 방식보다 나은 이유는 무엇입니까?저는 제가 모르는 다른 사용 사례가 있다고 생각하지만, 이것을 식별할 수 없습니다.

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

갱신하다

저는 그 이후로 봄을 배우기 시작했고 이제 이것이 훨씬 더 말이 됩니다.아래 단락은 Spring in Practice의 예를 들어 본 것입니다.AccountService차로례, 인스를사의 AccountDao긴 인용문에 대해 사과하지만 주입된 리소스가 표준 초기화보다 더 나은 것을 제공하는 이유에 대해 정말로 핵심을 파악한다고 생각합니다.

새 키워드를 사용하여 계정 서비스를 구성할 수도 있지만 서비스 계층 개체를 생성하는 것이 그렇게 간단한 경우는 거의 없습니다.그들은 종종 DAO, 메일 보낸 사람, SOAP 프록시 등에 의존합니다.계정 서비스 생성자에서(또는 정적 초기화를 통해) 이러한 각 종속성을 프로그래밍 방식으로 인스턴스화할 수 있지만, 이로 인해 종속성이 강화되고 교체 시 변경 사항이 단계적으로 발생합니다.

또한 외부적으로 종속성을 생성하고 setter 메서드 또는 생성자 인수를 통해 AccountService에 종속성을 설정할 수 있습니다.이렇게 하면 하드 내부 종속성이 제거되지만(인터페이스에 의해 계정 서비스에 선언된 경우) 초기화 코드가 곳곳에 중복됩니다.DAO를 생성하고 계정 서비스에 Spring 방식으로 연결하는 방법은 다음과 같습니다.

<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>

위와에서 위같이콩구후다인요수있청다습의 할 수 .AccountServiceSpring Application Context 및 Spring DI 프레임워크는 인스턴스화가 필요한 모든 항목을 관리합니다.

CDI를 쓴 사람들은 여러분에게 하나의 큰 물체 공장을 주었습니다. 그들은 여러분을 위해 일을 했습니다. 여러분보다 더 잘 했습니다.XML 구성 또는 주석 기반이므로 모든 것을 코드에 포함시킬 필요가 없습니다.

스프링과 같은 의존성 분사 엔진은 공장보다 훨씬 더 많은 일을 합니다.그들이 제공하는 모든 것을 복제하려면 하나 이상의 공장 클래스와 한 줄의 코드가 필요합니다.

물론 사용할 필요는 없습니다.여러분은 항상 여러분 자신의 바퀴를 발명할 수 있습니다.바퀴를 만들거나 의존성을 없애는 방법을 배우는 것이 목적이라면 그렇게 해야 합니다.

하지만 애플리케이션을 개발하고 싶다면 다른 사람이 제공하는 툴을 사용하는 것이 좋습니다.

의존성 주입에 관한 중요한 기사는 마틴 파울러에 의해 쓰여졌습니다.저는 그것을 읽는 것을 추천합니다. 8년 후에도 여전히 훌륭합니다.

"아직도 무엇이 더 있는지 명확하지 않습니다."

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

1. 느슨한 결합
2. 간편한 테스트
3. 더 나은 계층화
4. 인터페이스 기반 설계
5. 동적 프록시(AOP로 전환).

종속성 주입을 사용하는 목적은 주입된 것을 사용하는 코드가 공장에 종속성을 갖지 않도록 하는 것입니다.공장 코드 예제에서는 DI 접근 방식에 필요하지 않은 정적 메서드 호출이 코드에 포함되어 있습니다.

주사를 맞는 것은myFoo공장에 대해 알 필요가 없습니다.DI와합니다. 가 있는 , 개체의 Foo 또는 모의 Foo를 할 수 있으며, Factory를 . 특히 Foo가 있는 Bar 개체가 있는 경우, 해당 Bar 개체의 테스트는 Foo Factory를 포함하지 않고 Foo 또는 모의 Foo를 직접 생성하여 Bar에 배치할 수 있으며 Foo Factory를 작성할 필요가 없습니다.애플리케이션 비즈니스 논리를 구현하는 데 아무런 도움이 되지 않는 상용 플랫폼입니다.

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

컨텍스트와 종속성이라는 이름이 잘 선택되었습니다.

CDI는 더 나은 코드나 더 깨끗한 코드와는 아무런 관련이 없으며, 대규모 조직이 복잡하고 분산된 소프트웨어 시스템을 구축하고 데이터를 공유할 수 있도록 보장하는 것입니다.정부나 다른 관료들이 통제하는 모든 소프트웨어에 대해 독립적이고 문서화된 패키지를 무차별적으로 배포할 수 있도록 100% 보장하는 것입니다.요즘은 사실상 모든 POJO를 주입할 수 있다는 것을 기억하세요.

예를 들어, 클라이언트 앱을 구축하고 있으며 구석에 사용자의 이름을 인쇄하기를 원한다고 가정해 보겠습니다.

• 이 대기업의 엔터프라이즈 설계자는 귀하가 이러한 기능을 보유하기를 원하지만, 하위 소프트웨어 엔지니어로서 귀하가 DB의 키를 넘겨받을 가능성은 없습니다.

• 또한 네트워크를 통해 데이터를 보호하고 싶지만, 회사는 데이터 조각을 공유해야 할 때마다 인증 클라이언트를 재설계하기 위해 엔지니어에게 비용을 지불하지 않습니다.

• 그들은 당신이 이 정보를 조회하고 업데이트할 수 있기를 원하지만, 거래가 어떤 앱보다 높은 수준에서 처리되기를 원합니다.

• 그들은 설정 블록에서 사소한 모의실험으로 수업을 테스트할 수 있기를 원합니다.

• 이들은 최소한의 정적 방법을 사용하여 클래스 간 결합을 참조하십시오.

• 그리고 계속해서 계속해서...

대부분의 JSR은 내부 어딘가에 "EA가..."가 묻혀 있을 것입니다.

CDI는 대규모 앱을 허용하기 때문에 선호됩니다(임의?).수평 및 수직 스케일을 사용하여 컨텍스트, 종속성 및 데이터를 공유할 수 있습니다.

파울러의 말에 따르면:

"문제는 제가 어떻게 링크를 만들 수 있는지입니다. 그러면 제 리스터 클래스는 구현 클래스에 대해 무지하지만 인스턴스와 대화하여 작업을 수행할 수 있습니다."

그러나 이 시스템을 다른 방식으로 구현하려면 플러그인을 사용하여 이러한 서비스와의 상호 작용을 처리해야 합니다. 그래야 서로 다른 구현을 다른 구현에서 사용할 수 있습니다."

"이러한 컨테이너가 사용하는 접근 방식은 플러그인 사용자가 별도의 어셈블리 모듈이 구현을 리스터에 주입할 수 있도록 허용하는 어떤 관례를 따르도록 하는 것입니다."

간단히 말해서, 복잡한 엔터프라이즈 애플리케이션의 중앙 집중식 "명령 및 제어"가 가능합니다.Java EE는 체계화되고 신뢰할 수 있는 추상화 프로세스이며 CDI는 매우 잘 작동하여 거의 보이지 않게 만듭니다.복잡한 앱의 연결을 거의 단순하게 만듭니다.

두 가지 더 있습니다.

1. CDI는 Java EE에서 JNDI로 알려진 "서비스 로케이터 패턴"과 함께 평화롭게 존재하며, 이는 클라이언트 개발자가 동일한 유형의 여러 대안 중에서 선택해야 할 경우 선호됩니다.

2. CDI는 많은 경우, 특히 비기업(문자 그대로)의 경우에 필요한 것보다 더 강력합니다.

CompSci의 대부분의 것과 마찬가지로 높은 수준에서 응용 프로그램에서 다음과 같이 하드 코딩될 수 있는 간접(또는 추상화) 수준을 제공합니다.Foo myFoo = new Foo();이러한 간접적인 방식은 느슨하게 결합된 코드를 제공하며, 이 코드는 사물을 모듈식으로 만들어 클래스나 하위 시스템을 보다 간단한 방식으로 쉽게 교체, 서비스, 테스트할 수 있게 합니다.

방향/추상화에는 여러 가지 설계와 패턴이 있습니다. 의존성 주입은 하나일 뿐입니다.

당신의 질문의 다른 측면은 "왜 CDI인가?"입니다. 왜냐하면 누군가가 이미 당신을 위해 일을 해줬기 때문입니다.언제든지 자신만의 것을 만들 수 있지만, 예산과 시간에 맞춰 수행해야 하는 실제 시스템을 만드는 것이 목표일 때는 대개 시간 낭비입니다.당신을 위해 기꺼이 그 일을 해줄 미슐랭 스타 셰프가 있는데 왜 식료품과 요리에 신경을 쓰나요?

언급URL : https://stackoverflow.com/questions/13047807/why-use-cdi-in-java-ee