나는 우리가 영속 계층을 어떻게 노출할지 결정할 필요가있는 프로젝트를 진행 중이다.EJB3 대 데이터 액세스 객체
1) 일반의 DAO를 사용
현재 테이블에 두 개의 옵션이 있습니다. 이것들은 인터페이스를 구현하고 EJB 인 Business Components에서 (Weld를 사용하여) 주입 될 것입니다. 내부적으로 그들은 영속성을 위해 JPA/Hibernate를 사용할 것입니다.
2) Weld를 사용하여 DAO를 주입하는 대신 EJB로 구현하고 비즈니스 구성 요소에서 @EJB를 주입합니다.
기능을 사용하지 않을 때 지속성 계층에 EJB를 사용하는 것이 합리적입니까 (예 : 트랜잭션 관리 - 비즈니스 계층에서이를 처리)?
EJB over Weld (또는 다른 방법으로 라운드)를 사용할 때 성능상의 불이익이 있습니까?
어떤 옵션을 선택하는 것이 가장 좋을까요?
EJB를 JPA 기반 DAO에 사용하는 것은 완벽하게 자연 스럽습니다.
비즈니스 계층 (일반적으로 언급 한대로 EJB 임)에서 트랜잭션이 정상적으로 시작되면 트랜잭션이 자연스럽게 트랜잭션에 전파됩니다. DAO를 별도로 사용하려면 트랜잭션이 시작됩니다. 지금은이 기능을 사용할 수 없지만 필요할 때마다 무료로 제공됩니다.
또한 자체 트랜잭션에서 단일 작업을 수행해야하는 경우 DAO가 EJB 기반 일 때 사소한 작업입니다.
DAO EJB를 사용하여 비즈니스 EJB를 주입하면 성능상의 이점이있을 수 있습니다. 풀링 된 인스턴스에 위임 한 스텁 만 주입되므로 주입이 비교적 저렴합니다. 매번 호출 할 때마다 모든 DAO가 필요할 수도 있고 그렇지 않을 수도있는 비즈니스 EJB를 주입 할 수 있습니다. 나는 CDI가 똑같은 능력을 가지고 있는지 100 % 확신하지 못합니다. 물론 범위 지정 및 대화는 있지만 풀에 위임하기위한 스텁이 아닙니다.
JPA의 extended persistence context이 필요한 경우, 실제로 상태 유지 세션 빈이 만들어집니다. 그렇지 않으면 상태 비 저장 세션 빈이 DAO에 사용됩니다.
즉, CDI는보다 현대적인 구성 요소 모델이며 현재의 생각은 EJB가 결국 CDI 주석 집합으로 개조 될 것으로 보입니다. CDI 코드베이스 및 지식을 구축하기 시작하면 실제로 장기적인 전략적 이점이 될 수 있으므로 CDI가 필요합니다.
직접 질문에 대답하십시오 : 그렇습니다. 영속성 계층에 EJB를 사용하는 것이 맞지만 EJB 또는 CDI는 모두 입니다. 여기에서 선택하십시오.
매우 상세한 답장. 주요 관심사는 다음과 같습니다. 테이블 당 하나의 DAO가 있으면 DAO 인스턴스 풀을 생성하는 것이 너무 어려울 수 있습니다. EJB 3.1의 새로운 @Singleton Bean을 사용하는 것이 합리적일까요? 또한 DAO 수준에서 트랜잭션을 사용하지 않으며이를 사용할 계획은 없으며 다른 EJB 기능 (예 : 보안)을 사용할 계획입니다.내가 읽은 바에 따르면, 이것은 EJB 또는 CDI 사용 사이의 결정자 여야합니다. 어떻게 생각해? –
* 테이블 하나당 하나의 DAO를 가지고 있다면, DAO 인스턴스 풀을 생성하는 것이 조금 너무 많을 수 있습니다 * - 이것에 대해 걱정할 필요가 없습니다. 인스턴스는 필요에 따라 생성되며 선행으로 생성되지 않습니다. 즉, 여러 가지 DAO가 포함 된 비즈니스 빈을 주입 할 수 있으며 스텁 만 주입되며 실제로 스텁에 액세스 할 때 인스턴스가 만들어집니다. 그 후에 인스턴스는 풀에 보관됩니다. 수영장에 대해 걱정할 경우 조정할 수 있습니다 (최대 지속성, 최대 인스턴스 유지). 그러나 이는 실제로 거의 문제가되지 않습니다. –
'컨테이너'에 배포하고 있습니까? 어떤 컨테이너 요? EJB3 *를 사용하면 잠재적으로 배포가 더욱 간단해질 수 있습니다. JEE6 IMHO를 사용하면 EJB를 피할 이유가 거의 없으며 많은 경우 *를 사용합니다. 2p 가치. –
여분의 EJB 기능 (예 : 보안, 트랜잭션 ...)이 전혀 필요없는 경우는 어떻습니까? CDI가 좋은 후보자라고 생각합니까? –