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

https://stackoverflow.com/questions/68527

09-06-2019
|

문제

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

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

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

EJB3와 Spring에 대한 찬성 또는 반대 주장은 무엇입니까?
- 각각 어떤 위험을 예상할 수 있나요?
- 좋은 벤치마크 정보는 어디서 찾을 수 있나요?

해결책

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

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

다른 팁

EJB3와 Spring 사이의 격차는 분명히 이전보다 훨씬 작습니다.그렇긴 하지만, 현재 EJB3의 단점 중 하나는 빈에만 주입할 수 있기 때문에 컴포넌트를 필요 없는 빈으로 바꿀 수 있다는 것입니다.

단위 테스트에 대한 논쟁은 이제 상당히 부적합합니다. EJB3는 확실히 더 쉽게 단위 테스트가 가능하도록 설계되었습니다.

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

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

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

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

각각 어떤 위험을 예상할 수 있나요?이것을 EJB3에 비해 지속성 문제(Spring+JPA)로 취급한다면 실제로 그렇게 큰 선택을 하지 않는 것입니다.

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

나는 봄보다 확실히 EJB3를 추천하고 싶습니다.우리는 이것이 더 간소화되고, 코딩하기가 더 좋으며, 더 나은 지원을 받는다는 것을 알았습니다.나는 과거에 Spring을 사용해 본 적이 있으며 그것이 매우 혼란스럽고 EJB3(또는 JPA라고 생각합니다)만큼 잘 문서화되어 있지 않다는 것을 알았습니다.

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

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

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

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

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

세션 빈은 주로 의존성 주입과 트랜잭션으로 요약됩니다.그래서 EJB3와 Spring은 실제로 비슷합니다.Spring이 우위에 있는 곳은 JMS와 같은 것에 대한 더 나은 종속성 주입 및 더 나은 추상화입니다.

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

귀하의 질문에 관하여 :

EJB3와 Spring에 대한 찬성 또는 반대 주장은 무엇입니까?

전문가의 답변을 읽어 보시기 바랍니다. 다음에 대한 답변:Mark Fisher의 EJB 3 및 스프링 비교 분석.Reza Rahman의 발언(EJB 3.0)을 찾으려면 댓글을 읽어보세요.

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

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

나는 EJB가 좋은 구성 요소 기술이지만 좋은 프레임워크는 아니라고 생각합니다. Spring은 현재 사용할 수 있는 최고의 프레임워크입니다. 따라서 프레임워크 측면에서 Spring을 JEE의 최고의 구현으로 간주해야 하며 모든 작업에서 Spring을 사용하는 것이 좋습니다. 모든 구성 요소 기술과 쉽게 통합할 수 있는 유연성을 제공하는 프로젝트입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow