it-swarm-korea.com

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

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

우리는 비즈니스 로직에 어떤 서버 기술을 사용해야할지에 대한 어려움에 도달했습니다. EJB3와 Spring 사이에서 가장 큰 논점은 확장 성과 성능, 그리고 코드베이스의 유지 관리 성이라는 가장 큰 관심사입니다.

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

  1. EJB3 vs Spring의 주장은 무엇인가?
    • 각각 어떤 함정을 기대할 수 있습니까?
    • 좋은 벤치 마크 정보는 어디서 찾을 수 있습니까?
71
Justin Standard

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

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

EJB3와 Spring의 차이는 분명히 그보다 훨씬 작습니다. 즉, EJB3의 단점 중 하나는 Bean에만 삽입 할 수 있으므로 구성 요소를 필요하지 않은 Bean으로 전환 할 수 있다는 것입니다.

단위 테스트에 대한 논쟁은 이제는 관련이 없습니다. EJB3는보다 쉽게 ​​단위 테스트가 가능하도록 설계되었습니다.

위의 호환성 주장은 EJB3이든 Spring이든 관계없이 트랜잭션 관리자, JMS 등의 타사 제공 구현에 여전히 의존합니다.

그러나 나를 위해 스윙하는 것은 지역 사회의 지원입니다. 작년 EJB3 프로젝트를 진행하면서 많은 사람들이 프로젝트를 사용하고 문제에 대해 이야기하지 않았습니다. 옳고 그름의 봄은 기업에서 매우 널리 퍼져 있으며 특히 해결하려는 문제가 동일한 사람을 쉽게 찾을 수 있습니다.

37
PEELY

EJB3 대 Spring에 대한 또는 반대 주장은 무엇입니까? Spring은 항상 혁신적이며 실제 제약 조건을 인식합니다. Spring은 Java 1.4 애플리케이션 서버에 단순성과 우아함을 제공했으며 2004-2006 년에는 아무도 액세스 할 수 없었던 J2EE 스펙 버전을 필요로하지 않았습니다.이 시점에서 거의 종교적입니다 Spring + abstraction + open-source vs Java Enterprise Edition (Java EE) 5.0) 사양에 빠질 수 있다는 논쟁.

Spring 이 Java EE 사양과 경쟁하는 것 이상을 보완한다고 생각합니다. 스프링 고유의 기능은 계속 많은 사람들은 EJB 3이 대부분의 내부 비즈니스 애플리케이션에 적합한 '충분한'기능을 제공한다고 주장한다.

각각으로 어떤 함정을 기대할 수 있습니까? 이것을 EJB 3 대 지속성 문제 (Spring + JPA)로 취급한다면 실제로 큰 선택을하지 않습니다.

좋은 벤치 마크 정보를 어디에서 찾을 수 있습니까? 나는 specj 벤치 마크 결과 를 따르지 않았지만 인기가있었습니다. 잠시. 각 공급 업체 (IBM, JBOSS, Oracle 및 Sun)는 호환 서버를 갖는 데 점점 더 관심이없는 것 같습니다. 1.3, 1.4에서 갈수록 인증 된 공급 업체가 더 짧고 짧아집니다. 1.5 Java Enterprise Edition. 모든 사양을 완벽하게 준수하는 거대한 서버의 시대는 끝났다고 생각합니다.

18
Brian

스프링보다 EJB3을 추천합니다. 우리는 더 능률적이고 코드 작성이 더 좋으며 더 잘 지원된다는 것을 알게되었습니다. 나는 과거에 Spring을 사용했고 EJB3 (또는 JPA가 끝날 때 추측하는 JPA)만큼 문서화되지 않았고 매우 혼란 스럽습니다.

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

나는 몇 주 동안 시험해 보았으므로 봄에 대해서는 그렇게 많이 말할 수 없습니다. 그러나 내 전반적인 인상은 매우 나빴습니다. 그렇다고 프레임 워크가 나쁜 것은 아니지만 여기서 우리 팀은 EJB3가 지속성/비즈니스 계층에 가장 적합하다는 것을 알았습니다.

9
rustyshelf

EJB3보다 Spring을 선호하는 경향이 있지만 EJB3과 함께 작동하는 @PostConstruct, @PreDestroy 및 @Resource와 같은 JSR 주석과 같이 POJO 작성을 고수하고 가능한 경우 표준 주석을 사용하십시오. 또는 Spring을 사용하여 원하는 프레임 워크를 선택할 수 있습니다.

예 : IoC 대신 Guice를 사용하도록 프로젝트를 결정할 수 있습니다.

웹 응용 프로그램에서와 같이 사전 요청 주입을 사용하려면 Guice가 Spring보다 종속성 주입이 훨씬 빠릅니다.

세션 빈은 대부분 의존성 주입과 트랜잭션으로 요약됩니다. EJB3와 Spring은 실제로 비슷합니다. Spring이 Edge를 가지고있는 곳은 JMS와 같은 것들에 대한 더 나은 의존성 주입과 더 나은 추상화에 있습니다.

7
James Strachan

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

2
Soumitra

당신의 질문에 관하여 :

EJB3 대 Spring의 주장은 무엇입니까?

나는 전문가들의 답변을 읽는 것이 좋습니다 : 마크 피셔의 EJB 3 및 스프링 비교 분석에 대한 응답 . 주석을 읽고 Reza Rahman의 발언 (EJB 3.0)을 찾으십시오.

1
krams

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

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

0
kamal.gs