EJB 3 대신 Spring + Hibernate가 선호됩니까?

새로운 JEE 프로젝트가 시작될 때마다 (이러한 기술이 적용될 수있는 경우) 사람들은 EJB 3 대신 Spring + Hibernate의 조합을 선호합니다.

주니어 프로그래머 에게는 EJB 대신 대신 사용하는 것이 좋습니다 .

이 개인적 선호가 있습니까, 아니면 적절한 이유가 있습니까? (예 : EJB 또는 기술 불확실성 대 성능상의 이유 또는 학습 곡선에 불신을 일으킨 이전 EJB 버전에서 생성 된 개인적인 흉터)?

EJB 3+ 프레임 워크는 어노테이션 구성 지속성 프레임 워크 및 어노테이션 구성 종속성 주입을 허용하는 CDI에 대한 응답으로 JPA와 함께 제공되므로 실제로 매우 좋습니다. 또한 해당 용접 위에 추가합니다. 반면 Spring은 이제 주석을 통한 구성으로 게임에서 따라 잡고 있습니다.

EJB1과 2에 대한 역사적 반발은 할인되어서는 안된다. 그들은 단지 엔터프라이즈 응용 프로그램을 작성의 문제점을 해결하기 위해 실패하지 않았다, 그들은 화려 하지 못했습니다. 엔터프라이즈 및 웹 응용 프로그램 개발자가 직면 한 실제 문제를 파악하고 실제로 필요한 솔루션을 제공하는 것은 디자이너 측의 완전한 실패였습니다.

현재 Java의 현재 방향에 대한 심각한 흔들림과 불안정성이 있으며 Oracle의 기존 Sun JVM의 현재 책임자와 소유자에 대한 믿음이 부족하다는 불신을 추가하십시오. 많은 사람들이 Oracle이 Java를 개선하고 방향을 이끌 것이라고 믿지 않으며 Apache Software Foundation이 타월에 빠져들지도 모른다는 두려움도 있습니다. 점점 더 많은 사람들이 Java의 미래를 위해 OpenJDK를 찾고 있지만 엔터프라이즈 채택이 필요한 곳은 아닙니다.

일부는 엔터프라이즈 애플리케이션이 Java가 역사적으로 오랫동안 세계 최고의 프로그래밍 언어 인 이유 중 하나 인 주요 원인이기 때문에이 모든 것을 죽음의 냄새라고 생각합니다. 그렇기 때문에 Microsoft는 .NET 기술을 사용하여 Java에 대해 많은 기반을 확보하고 있습니다.

비 엔터프라이즈 기반 Java 애플리케이션 개발자는 솔루션을 빌드하는 데 도움을주기 위해 OpenJDK 및 기타 오픈 소스 프레임 워크를 향해 점점 더 많은 방향을 돌리고 있으며 일부는 결코 되돌아 보지 않습니다. 기술적으로 JEE가 유사한 Spring 애플리케이션과 정면으로 맞설 수는 있지만 JEE를 정당성의 최전선으로 되 돌리는 데 너무 늦었다 고 말할 수 있습니다.

EJB에는 많은 수하물이 있습니다. 수하물의 일부는 잘못된 고객을 대상으로한다는 사실에서 비롯됩니다. 다른 부분은 처음 두 버전이 완전히 쓰레기라는 것이었다.

원래 EJB 버전을 살펴보면 EJB 개발자가 EJB 호환 컨테이너 내에서 사용할 수있는 패키지 솔루션을 만들 수 있다는 것입니다. 인하 우스 샵에서는이 수준의 추상화가 불필요했습니다. 타사 EJB 구성 요소 공급 업체를 위해 번창하는 시장을 만드는 완벽한 솔루션이었습니다. 그러나 컨테이너 공급 업체는 마케팅에 열심을 보이며 매일 개발을위한 실용적인 솔루션으로 제품을 판매하고있었습니다. 이는 모든 응용 프로그램 코드를 COM + 구성 요소로 작성하는 것과 같습니다.

원래 J2EE 사양에 대한 배경 지식을 더 많이 제공하기 위해 관련 공급 업체 대부분에 CORBA 서버가 있었고 앞으로 이러한 제품을 활용하려고했습니다. EJB 사양은 IIOP 프로토콜 (실제로는 IIOP보다 얇은 계층 인 Java RMI)을 통해 구축되었습니다. CORBA는 그 복잡성으로 인해 이미 거부되었으며, EJB는 위장 된 CORBA 일 뿐이므로 CORBA의 많은 문제가 발생했습니다. 실제로 EJB의 추상화는 순수한 CORBA 구현보다 작업하기가 더 어려워졌습니다.

고무가 포장 도로에 닿자 사람들은 EJB 성능이 끔찍하다는 것을 깨달았습니다. 모든 전화가 원격 전화이고 응용 프로그램을 시작하고 올바르게 시작하기가 어려워지면서 사람들은 신속하게 대안을 찾았습니다. JSP 컨테이너에서 실행되는 최대 절전 모드 및 스프링이 솔루션이되었습니다.

EJB 3은이 접근법을 "채택했다". 그러나 여전히 많은 이점을 제공하지 않는 일반적인 타협입니다. 여전히 타사 EJB 구성 요소 시장이 없으므로 EJB 컨테이너를 사용하여 솔루션을 빌드 할 필요가 없습니다.

긴 이야기가 짧습니다. EJB 3은 처음 두 번의 반복에 비해 크게 개선 되었지만 여전히 비용보다 큰 이점을 제공하지는 않습니다.