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

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

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

어떤 서버 기술을 비즈니스 로직에 사용할 것인지에 관해서는 난관에 봉착했습니다.EJB3와 Spring 사이의 큰 논쟁은 확장성과 성능, 그리고 코드 기반의 유지보수성이 가장 큰 관심사입니다.

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

1. EJB3 대 스프링에 대한 찬성 또는 반대 주장은 무엇입니까?
   • 각각 어떤 함정을 예상할 수 있습니까?
   • 어디서 좋은 벤치마크 정보를 찾을 수 있습니까?

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

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

EJB3와 스프링 사이의 간격은 이전보다 훨씬 작습니다.그렇기는 하지만, 지금 EJB3의 단점 중 하나는 콩에만 주입할 수 있기 때문에 성분을 필요 없는 콩으로 만들 수 있다는 것입니다.

유닛 테스트에 대한 논쟁은 지금은 전혀 관련이 없습니다. EJB3는 보다 쉽게 유닛 테스트를 할 수 있도록 설계되었습니다.

위의 호환성 논쟁도 무관합니다. EJB3를 사용하든 Spring을 사용하든 트랜잭션 관리자, JMS 등의 타사 구현에 여전히 의존합니다.

하지만 제게 필요한 것은 지역사회의 지원입니다.작년에 EJB3 프로젝트를 수행하면서 EJB3를 사용하고 문제에 대해 이야기하는 사람이 별로 없었습니다.봄은 옳든 그르든 간에, 특히 기업에 만연해 있으며, 이를 통해 해결하고자 하는 문제와 동일한 문제를 가진 사람을 쉽게 찾을 수 있습니다.

EJB3 대 스프링에 대한 찬성 또는 반대 주장은 무엇입니까?봄은 항상 혁신적이고 현실의 제약을 인식합니다.Spring은 Java 1.4 애플리케이션 서버에 단순함과 우아함을 제공했으며 2004년에서 2006년 사이에는 아무도 접근할 수 없었던 J2EE 사양 버전이 필요하지 않았습니다.이 시점에서 봄 + 추상화 + 오픈 소스 대 Java Enterprise Edition(Java EE) 5.0 사양으로 빨려 들어갈 수 있는 종교적 논쟁입니다.

저는 봄이 자바 EE 사양과 경쟁하는 것 이상으로 보완한다고 생각합니다.한때 Spring에만 국한되었던 기능들이 계속 사양에 포함됨에 따라 EJB 3가 대부분의 내부 비즈니스 애플리케이션에 '충분히 적합한' 기능 세트를 제공한다고 주장하는 사람들이 많을 것입니다.

각각 어떤 함정을 예상할 수 있습니까?이 문제를 지속성 문제로 취급하는 경우(Spring+J)PA) 대 EJB3 간에 당신은 그렇게 큰 선택을 하지 못하고 있습니다.

어디서 좋은 벤치마크 정보를 찾을 수 있습니까?한동안 specj 벤치마크 결과를 따라가지 않았지만 한동안 인기가 많았습니다.각 벤더(IBM, JBOSS, Oracle 및 Sun)는 규정 준수 서버에 대한 관심이 점점 줄어들고 있는 것으로 보입니다.이 목록은 1.3, 1.4.1.5 Java Enterprise Edition으로 갈수록 인증된 공급업체보다 점점 짧아집니다.모든 사양을 완벽하게 준수하는 거대한 서버의 시대는 끝났다고 생각합니다.

저는 봄에 EJB3를 꼭 추천하고 싶습니다.더 능률적이고, 코드화하기 더 좋으며, 더 나은 지원을 받을 수 있습니다.예전에 Spring을 사용한 적이 있는데 매우 혼란스러웠고 EJB3만큼 문서화가 잘 되어있지는 않았습니다(또는 JPA는 하루가 끝날 때쯤 되면).

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

봄에 대해서는 몇 주 동안만 해봤기 때문에 그렇게 많이 말할 수는 없습니다.하지만 전체적인 인상은 매우 좋지 않았습니다.그렇다고 해서 프레임워크가 나쁜 것은 아니지만, 우리 팀은 EJB3가 지속성/비즈니스 계층에 가장 적합하다고 판단했습니다.

저는 EJB3보다 Spring을 선호하는 경향이 있지만, 여러분이 어떤 접근 방식을 취하든 POJO를 작성하는 것을 고수하고 가능한 경우 표준 주석을 사용하는 것이 좋습니다. 예를 들어, EJB3 또는 Spring과 함께 작동하는 JSR 주석인 @PostConstruct, @PreDestroy 및 @Resource를 사용하여 원하는 프레임워크를 선택할 수 있습니다.

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

웹 애플리케이션에서와 같이 사전 요청 주입을 사용하려면 Guice가 Spring보다 의존성 주입이 훨씬 빠르다는 것을 알 수 있습니다.

세션 원두는 대부분 의존성 주입과 거래로 압축됩니다. 따라서 EJB3와 Spring은 이와 매우 비슷합니다.Spring이 우위에 있는 곳은 JMS와 같은 것에 대한 더 나은 의존성 주입과 더 나은 추상화에 있습니다.

나는 과거에 아주 비슷한 건축물을 사용한 적이 있습니다.Flex Data Services와 결합하면 Spring + Java 1.5 + Actionscript 2/3이 매우 쉽고 재미있게 코딩할 수 있습니다.하지만 Flex 프런트 엔드는 충분히 강력한 클라이언트 시스템이 필요하다는 것을 의미합니다.

질문과 관련하여:

EJB3 대 스프링에 대한 찬성 또는 반대 주장은 무엇입니까?

전문가의 응답을 읽어 볼 것을 제안합니다: EJB 3 및 Mark Fisher의 스프링 비교 분석에 대한 응답입니다.코멘트를 읽고 Reza Rahman의 발언(EJB 3.0)을 찾아 보십시오.

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

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

저는 EJB가 좋은 부품 기술이지만 좋은 프레임워크는 아니라고 생각합니다.봄은 오늘날 사용할 수 있는 최고의 뼈대입니다.그래서 저는 프레임워크의 의미에서 봄을 JEE의 최상의 구현으로 생각해야 하며, 모든 프로젝트에서 봄을 사용하여 어떤 부품 기술과도 쉽게 통합할 수 있는 유연성을 제공하는 것을 추천합니다.

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