CDI와 EJB는 어떻게 비교됩니까? 상호 작용?

나는 두 사람이 어떻게 상호 작용하는지 그리고 그들 사이의 경계가 어디에 있는지 이해하는 데 어려움을 겪고 있습니다. 중복됩니까? 그들 사이에 중복이 있습니까?

둘 다 관련된 주석이 있다는 것을 알고 있지만 간략한 설명이 포함 된 전체 목록을 찾을 수 없었습니다. 이것이 어떻게 다른지 또는 겹치는지를 명확히하는 데 도움이 될지 확실하지 않습니다.

정말 혼란 스러워요. 나는 EJB를 합리적으로 잘 이해하고 있다고 생각합니다. CDI가 테이블에 제공하는 것과 EJB가 이미 제공하는 것을 대체하거나 향상시키는 방법을 정확히 이해하는 데 어려움을 겪고 있다고 생각합니다.

CDI : 의존성 주입에 관한 것입니다. 이는 어디에서나 인터페이스 구현을 삽입 할 수 있음을 의미합니다. 이 객체는 무엇이든 될 수 있으며 EJB와 관련이 없을 수 있습니다. 다음 은 CDI를 사용하여 랜덤 생성기를 주입하는 방법의 예입니다. EJB에는 아무것도 없습니다. 비 EJB 서비스, 다른 구현 또는 알고리즘을 삽입하려는 경우 CDI를 사용합니다 (따라서 EJB가 전혀 필요하지 않음).
EJB : 당신은 이해하고 아마도 @EJB어노테이션에 의해 혼란 스러울 것입니다. 그것은 당신의 서비스 또는 무엇이든 구현을 주입 할 수있게합니다. 주된 아이디어는 주입하는 클래스가 EJB 컨테이너에 의해 관리되어야한다는 것입니다. CDI가 EJB가 무엇인지 이해하는 것 같으므로 Java EE 6 호환 서버에서 서블릿에서 둘 다 작성할 수 있습니다.

@EJB EJBService ejbService;

과

@Inject EJBService ejbService;

그것이 당신을 혼란스럽게 만들 수 있지만, 그것은 아마도 EJB와 CDI를 연결하는 유일한 다리 일 것입니다.

CDI에 대해 이야기 할 때 다른 개체를 CDI 관리 클래스에 삽입 할 수 있습니다 (CDI 인식 프레임 워크에 의해 생성되어야 함).

CDI가 제공하는 다른 것 ... 예를 들어, Struts 2를 MVC 프레임 워크로 사용하고 (예를 들어) EJB 3.1을 사용하더라도 여기에 제한이 있습니다. @EJBStruts 작업에서 주석을 사용할 수 없으며 컨테이너에서 관리하지 않습니다. 그러나 Struts2-CDI 플러그인을 추가 할 때 @Inject동일한 것에 대한 주석을 작성할 수 있습니다 (따라서 더 이상 JNDI 조회가 필요하지 않음). 이렇게하면 EJB 파워가 향상되지만 앞서 언급했듯이 CDI로 주입하는 것은 EJB와 관련이 있는지 여부는 중요하지 않습니다. 그것이 바로 파워입니다.

추신. 예제에 대한 업데이트 된 링크

현재 Java EE에는 여러 구성 요소 모델이 있으므로 실제로는 약간 혼란 스럽습니다. 그들은이다 CDI , EJB3 와 JSF 관리 콩 .

CDI 는 블록의 새로운 아이입니다. CDI 콩 기능 dependency injection, scoping그리고 event bus. CDI 빈은 주입 및 범위 지정과 관련하여 가장 유연합니다. 이벤트 버스는 매우 가볍고 가장 단순한 웹 애플리케이션에도 매우 적합합니다. 이 외에도 CDI는 portable extensions모든 구현 (Glassfish, JBoss AS, Websphere 등)에서 사용할 수있는 Java EE에 추가 ​​기능을 제공하는 일종의 플러그인 메커니즘 인 이라는 매우 고급 기능도 제공합니다. .

EJB3 Bean은 이전 레거시 EJB2 구성 요소 모델 ^* 에서 개조되었으며 주석을 통해 관리되는 Java EE의 첫 번째 Bean이었습니다. EJB3 콩 기능 dependency injection, declarative transactions, declarative security, pooling, concurrency control, asynchronous execution와 remoting.

EJB3 빈의 의존성 주입은 CDI 빈 에서처럼 유연하지 않으며 EJB3 빈에는 범위 지정 개념이 없습니다. 그러나 EJB3 빈은 트랜잭션이며 기본적으로 풀링됩니다 ^** , CDI가 EJB3 도메인에 남겨두기로 선택한 매우 유용한 두 가지입니다. 언급 된 다른 항목도 CDI에서 사용할 수 없습니다. EJB3에는 자체 이벤트 버스가 없지만 메시지를 수신하기위한 특별한 유형의 빈이 있습니다. 메시지 구동 빈. 이는 Java Messaging System 또는 JCA 자원 어댑터가있는 다른 시스템에서 메시지를 수신하는 데 사용할 수 있습니다. 단순 이벤트에 대해 완전한 메시지를 사용하는 것은 CDI 이벤트 버스보다 훨씬 무겁고 EJB3는 생산자 API가 아닌 리스너 만 정의합니다.

JSF Managed Bean 은 JSF가 포함 된 이후로 Java EE에 존재했습니다. 그들도 기능 dependency injection및 scoping. JSF Managed Beans는 선언적 범위 지정 개념을 도입했습니다. 원래 범위는 다소 제한되어 있었고 EJB3 빈이 이미 주석을 통해 선언 될 수있는 동일한 버전의 Java EE에서 JSF 관리 빈은 여전히 ​​XML로 선언되어야했습니다. JSF Managed Bean의 현재 버전도 최종적으로 주석을 통해 선언되고 범위는보기 범위와 사용자 정의 범위를 생성하는 기능으로 확장됩니다. 동일한 페이지에 대한 요청 사이의 데이터를 기억하는보기 범위 는 JSF Managed Bean의 고유 한 기능입니다.

보기 범위를 제외하고는 Java EE 6에서 JSF Managed Beans에 대한 것이 거의 없습니다. CDI에 누락 된보기 범위가 있습니다. 업데이트 : Java EE 7 / JSF 2.2에는 CDI 호환 @ViewScoped 가 추가되어 CDI가 실제로 완벽한 수퍼 세트가되었습니다. 업데이트 2 : JSF2.3에서 JSF 관리 빈은 CDI 관리 빈을 위해 더 이상 사용되지 않습니다.

EJB3와 CDI의 상황은 그렇게 분명하지 않습니다. EJB3 컴포넌트 모델 및 API는 CDI가 제공하지 않는 많은 서비스를 제공하므로 일반적으로 EJB3를 CDI로 대체 할 수 없습니다. 반면에 CDI는 EJB3와 함께 사용할 수 있습니다 (예 : EJB에 범위 지원 추가).

전문가 그룹 멤버이자 CanDI라는 CDI 구현의 구현자인 Reza Rahman은 EJB3 구성 요소 모델과 관련된 서비스를 CDI 주석 집합으로 개조 할 수 있음을 자주 암시했습니다. 그런 경우 Java EE의 모든 관리 Bean이 CDI Bean이 될 수 있습니다. 이것은 EJB3가 사라지거나 더 이상 사용되지 않음을 의미하는 것이 아니라 그 기능이 @Stateless 및 @EJB와 같은 EJB의 고유 한 주석 대신 CDI를 통해 노출된다는 것을 의미합니다.

최신 정보

TomEE 및 OpenEJB 명성의 David Blevins는 그의 블로그에서 CDI와 EJB의 차이점과 유사점을 잘 설명합니다. CDI, EJB를 깨뜨릴 때

_{* 버전 번호의 증가 일 뿐이지 만 EJB3 빈은 대부분 완전히 다른 종류의 빈이었습니다. 단순한 단일 어노테이션을 적용하여 "관리되는 빈"이되는 단순한 포조 (pojo)와 헤비급 및 매우 무거운 다양한 구성 요소 인터페이스를 구현하는 데 필요한 빈 외에도 모든 빈에 대해 지나치게 장황한 XML 배포 설명자가 필요했습니다.}

_{** Stateless 세션 Bean은 일반적으로 풀링되고 Stateful 세션 Bean은 일반적으로 풀링되지 않지만 가능합니다. 따라서 두 유형 모두에 대해 풀링은 선택 사항이며 EJB 사양은 어느 쪽이든 강제하지 않습니다.}

알버트 아인슈타인 : If you can't explain it simply, you don't understand it well enough

Ejbs와 CDI는 이해하기 매우 간단합니다.

Ejbs :

1. 항상 @Stateless, @Stateful, @Request 등과 같은 범위 한정자에 의해 주석이 추가됩니다.
2. Ejbs의 인스턴스는 Java EE 프레임 워크에 의해 제어되고 풀링됩니다. 소비자에게 인스턴스를 제공하는 것은 EE 프레임 워크의 의무입니다.

@Stateless

 public class CarMaker(){
    public void createCar(Specification specs){
        Car car = new Car(specs);
    }
}

CarMaker는 특정 Ejbs 범위로 주석이 달려 있으므로 Ejb입니다.

CDI :

1. EE 프레임 워크에 의해 완전히 관리되지 않으므로 인스턴스를 직접 만들어야합니다.

2. 항상 의존적입니다. 예를 들어 "종속"을 설명하겠습니다.

   class Specification { private String color; private String model; //- Getter and Setter }

Specification이 EJB 범위로 주석되지 않고이가 코드하지 EE 프레임 워크에 의해 초기화 이후 클래스는 CDI입니다. 여기서 주목해야 할 점은 Specification클래스에 주석을 달지 않았으므로 기본적으로 주석으로 주석 처리된다는 것 @Dependent입니다.

@Dependent  <- By default added 
class Specification { ... }

Further reading: Ejbs 범위 주석과 CDI 범위 주석 사이에 더 많은 것을 연구해야합니다.