비즈니스 계층에 EJB3 또는 Spring을 사용해야합니까?

비즈니스 계층에 EJB3 또는 Spring을 사용해야합니까?

---

우리 팀은 웹 프런트 엔드로 새로운 서비스 지향 제품을 개발하고 있습니다. 우리가 사용할 기술에 대한 논의에서 JBoss 애플리케이션 서버, Flex 프런트 엔드 (Adobe AIR를 사용하여 데스크톱 배포 가능) 및 웹 서비스를 실행하여 클라이언트와 서버를 인터페이스하는 것으로 결정했습니다.

비즈니스 로직에 어떤 서버 기술을 사용해야하는지에 관해서는 난관에 봉착했습니다. 큰 논쟁은 EJB3와 Spring 사이에 있으며, 우리의 가장 큰 관심사는 확장 성과 성능, 그리고 코드베이스의 유지 가능성입니다.

내 질문은 다음과 같습니다.

1. EJB3 대 Spring에 대한 논쟁은 무엇입니까?
   • 각각에 대해 어떤 함정을 기대할 수 있습니까?
   • 좋은 벤치 마크 정보는 어디에서 찾을 수 있습니까?

---

성능에 따라 EJB3와 Spring 사이에는 큰 차이가 없습니다. 다음과 같은 이유로 Spring을 선택했습니다 (질문에 언급되지 않음).

• Spring은 단위 테스트를보다 쉽게 ​​지원하는 방향으로 아키텍처를 구동합니다. 예를 들어, 모의 DAO 객체를 주입하여 비즈니스 계층을 단위 테스트하거나 Spring의 MockHttpRequest 객체를 사용하여 서블릿을 단위 테스트합니다. 테스트를 특정 계층으로 격리 할 수있는 단위 테스트를 위해 별도의 Spring 구성을 유지합니다.
• 최우선 드라이버는 호환성이었습니다. 둘 이상의 App Server를 지원해야하는 경우 (또는 결국 JBoss에서 Glassfish로 이동하는 옵션을 원할 경우), 서로 다른 구현 간의 호환성에 의존하지 않고 기본적으로 컨테이너 (Spring)를 휴대하게됩니다. EJB3 사양.
• Spring은 Persistence, object remoting 등에 대한 기술 선택을 허용합니다. 예를 들어, Flex 프런트 엔드도 사용하고 있으며 Flex와 Spring 간의 통신에 Hessian 프로토콜을 사용하고 있습니다.

---

EJB3와 Spring 사이의 간격은 분명히 이전보다 훨씬 작습니다. 즉, EJB3의 단점 중 하나는 빈에만 주입 할 수 있으므로 구성 요소를 필요하지 않은 빈으로 바꿀 수 있다는 것입니다.

단위 테스트에 대한 주장은 이제 상당히 무의미합니다. EJB3는 명확하게 단위 테스트가 가능하도록 설계되었습니다.

위의 호환성 인수도 약간 관련이 없습니다. EJB3를 사용하든 Spring을 사용하든 트랜잭션 관리자, JMS 등의 타사 제공 구현에 여전히 의존합니다.

그러나 나를 위해 흔들리는 것은 커뮤니티의 지원입니다. 작년에 EJB3 프로젝트를 진행하면서 많은 사람들이 그것을 사용하고 그들의 문제에 대해 이야기하지 않았습니다. 옳든 그르 든 Spring은 기업에서 매우 널리 퍼져 있으며 특히 해결하려는 문제를 가진 사람을 쉽게 찾을 수 있도록합니다.

---

EJB3 대 Spring에 대한 논쟁은 무엇입니까? Spring은 항상 혁신적이고 실제적인 제약을 인식합니다. Spring은 Java 1.4 애플리케이션 서버에 단순성과 우아함을 제공했으며 2004-2006 년에 아무도 액세스 할 수 없었던 J2EE 사양 버전이 필요하지 않았습니다. + 추상화 + 오픈 소스 대 Java EE (Java Enterprise Edition) 5.0 사양.

Spring 은 Java EE 사양과 경쟁 하는 것 이상을 보완 한다고 생각 합니다 . 한때 Spring에 고유했던 기능이 계속해서 사양에 포함됨에 따라 많은 사람들은 EJB 3가 대부분의 내부 비즈니스 애플리케이션에 '충분히 좋은'기능 세트를 제공한다고 주장 할 것입니다.

각각에 대해 어떤 함정을 기대할 수 있습니까? 이것을 지속성 문제 (Spring + JPA) 대 EJB3로 취급한다면 정말 큰 선택을하지 않는 것입니다.

좋은 벤치 마크 정보는 어디에서 찾을 수 있습니까? 나는 다음에하지 않은 specj 벤치 마크 결과 언젠가를 들어,하지만 그들은 잠시 동안 인기가 있었다. 각 공급 업체 (IBM, JBOSS, Oracle 및 Sun)가 호환 서버를 갖는 데 점점 더 관심이없는 것 같습니다. 목록은 1.3, 1.4에서 갈수록 인증 된 공급 업체보다 더 짧아집니다. 1.5 자바 엔터프라이즈 에디션. 모든 사양을 완벽하게 준수하는 거대 서버의 시대는 끝났다고 생각합니다.

---

나는 봄보다 EJB3를 확실히 추천 할 것입니다. 우리는 그것이 더 능률적이고, 코딩하기 더 좋으며, 더 잘 지원된다는 것을 알게되었습니다. 나는 과거에 Spring을 사용했고 그것이 매우 혼란스럽고 EJB3 (또는 하루가 끝나면 JPA로 문서화되지 않음)

1. EJB3부터는 더 이상 외부 구성 파일을 처리 할 필요가 없으며 데이터베이스 테이블 당 하나의 POJO 만 주석을 달 수 있습니다. 이 POJO는 문제없이 웹 계층에 전달할 수 있습니다. Netbeans와 같은 IDE는 이러한 POJO를 자동으로 생성 할 수도 있습니다. 우리는 이제 EJB3를 대규모 애플리케이션의 백엔드로 사용했으며 성능 문제를 발견하지 못했습니다. Session Bean은 Flex 프런트 엔드에 노출 할 수있는 웹 서비스로 쉽게 노출 될 수 있습니다. Session Bean은 필요한 경우 역할과 같은 것을 할당하기 위해 메서드 또는 클래스 수준에서 쉽게 잠글 수 있습니다.

나는 봄에 대해 그다지 말할 수 없다. 나는 단지 몇 주 동안 그것을 시험해 보았 기 때문이다. 그러나 그것에 대한 전반적인 인상은 매우 나빴습니다. 그렇다고 프레임 워크가 나쁘다는 의미는 아니지만 여기 우리 팀은 EJB3가 지속성 / 비즈니스 계층에 가장 적합하다는 것을 발견했습니다.

---

나는 EJB3보다 Spring을 선호하는 경향이 있지만 내 권장 사항은 어떤 접근 방식을 취하 든 POJO를 작성하고 가능한 경우 표준 주석을 사용하는 것이 좋습니다. 또는 Spring을 사용하여 원하는 프레임 워크를 선택할 수 있습니다.

예를 들어 IoC 대신 Guice를 사용할 일부 프로젝트를 결정할 수 있습니다.

웹 애플리케이션에서와 같이 사전 요청 주입을 사용하려면 Guice가 Spring보다 종속성 주입에 대해 상당히 빠르다는 것을 알 수 있습니다.

세션 빈은 대부분 의존성 주입과 트랜잭션으로 귀결됩니다. 그래서 EJB3와 Spring은 정말 비슷합니다. Spring이 우위를 차지하는 곳은 JMS와 같은 것에 대한 더 나은 종속성 주입 및 더 나은 추상화에 있습니다.

---

나는 과거에 매우 유사한 아키텍처를 사용했습니다. Spring + Java 1.5 + Actionscript 2/3를 Flex Data Services와 결합하면 코드 작성이 매우 쉽고 재미있어졌습니다. 그러나 Flex 프런트 엔드는 적절하게 강력한 클라이언트 시스템이 필요함을 의미합니다.

---

귀하의 질문에 관하여 :

EJB3 대 Spring에 대한 논쟁은 무엇입니까?

전문가의 답변 : A RESPONSE TO : EJB 3 AND SPRING COMPARATIVE ANALYSIS by Mark Fisher . Reza Rahman의 발언 (EJB 3.0)을 찾으려면 댓글을 읽어보세요.

---

스프링을 선호하는 또 다른 점은 대부분의 다른 도구 / 프레임 워크가 스프링과의 통합을 더 잘 지원한다는 것입니다. 대부분 내부적으로 스프링을 사용합니다 (예 : activemq, camel, CXF 등).

또한 더 성숙하고 EJB3보다 훨씬 더 많은 리소스 (책, 기사, 모범 사례 등)와 숙련 된 개발자가 있습니다.

---

EJB는 좋은 컴포넌트 기술이지만 좋은 프레임 워크는 아니라고 생각합니다 .Spring은 현재 사용 가능한 최고의 프레임 워크입니다. 그래서 저는 Spring을 프레임 워크의 의미에서 JEE의 최고의 구현으로 생각해야합니다. 모든 구성 요소 기술과 쉽게 통합 할 수있는 유연성을 제공하는 프로젝트입니다.

참고 URL : https://stackoverflow.com/questions/68527/should-i-use-ejb3-or-spring-for-my-business-layer