[SPRING] Java EE 6 대 Spring 3 스택 [닫힘]

Java EE 6 대 Spring 3 스택 [닫힘]

나는 지금 새로운 프로젝트를 시작하고있다. 나는 기술을 선택해야한다. 나는 빛이 필요하므로 EJB 나 Seam이 필요 없다. 반면에 JPA (Hibernate 또는 Alternative)와 JSF (IceFaces)가 필요합니다.

Tomcat에 배치 된 Spring 3의 스택이 좋은 선택이라고 생각하십니까? 아니면 Java EE 6 웹 응용 프로그램이 더 좋을까요? Java EE 6은 아직 신기술이 아니며 아직 문서화되지 않았습니다. Tomcat은 Glassfish 3보다 유지 관리가 더 쉬운 것 같습니다.

당신 의견은 뭐니? 어떤 경험이 있습니까?

해결법

1. ==============================

   1.EJB3 이후로 EJB가 무거워지는 이유를 설명해 주시겠습니까? 우리가 2004 년에 더 이상 있지 않다는 것을 알고 있습니까? 빛과 당신의 주장에 대한 당신의 정의를 정말로 읽고 싶습니다. (그리고 저는 대답을 즐거움으로 업데이트 할 것입니다. 왜냐하면 저는 말할 수있는 몇 가지 단서가있을 것이라고 확신했기 때문입니다.)

   EJB3 이후로 EJB가 무거워지는 이유를 설명해 주시겠습니까? 우리가 2004 년에 더 이상 있지 않다는 것을 알고 있습니까? 빛과 당신의 주장에 대한 당신의 정의를 정말로 읽고 싶습니다. (그리고 저는 대답을 즐거움으로 업데이트 할 것입니다. 왜냐하면 저는 말할 수있는 몇 가지 단서가있을 것이라고 확신했기 때문입니다.)

   JSF 2.0, JPA 2.0, Bean 유효성 검사, EJB 3.1 Lite, CDI 등이 포함 된 Java EE 6 웹 프로파일은 완벽 할 것이며 GlassFish v3 Web Profile을 사용하여 Java EE 6 Web Profile으로 작성된 응용 프로그램을 실행할 수 있습니다 .

   글쎄, 독점 컨테이너 (Spring)보다는 비 독점 플랫폼 (Java EE)에서 코드를 실행하는 것을 좋아합니다. 그리고 Java EE 6는 충분하다고 생각합니다. (이것은 완곡 어법, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass)입니다. JSF 회의론자 였지만 두 번째를 보았고 CDI가있는 JSF 2.0은 너무 다르기 때문에 비교할 수도 없습니다. 그리고 당신이 CDI를 보지 않았다면, 그것이 CDI를 흔든다는 것을 말해 줄 것입니다.

   Java EE는 제게 잘 문서화되어 있습니다. 이것은 무료 주장처럼 들립니다. 그리고 저를 믿거 나 말거나, Java EE가 점점 복잡 해지는 동안 Spring이 복잡해지기 시작합니다.

   너 뭔가 해봤 니? 특별한 문제에 직면 했습니까? 다시 말하지만, 이것은 무료 주장처럼 들립니다.

2. ==============================

   2.나는 JavaEE6를 사용하지 않았다.

   나는 JavaEE6를 사용하지 않았다.

   그러나 JavaEE와 EJB의 모든 이전 버전의 JavaEE와 EJB를 사용하여 충분히 신뢰할 수 없게되었습니다. 사실 표준이 아닌 사실 표준으로 자리 잡을 때까지는 신뢰할 수 없습니다. 현재, Spring은 여전히 ​​사실상의 표준입니다.

   나를 속여, 부끄러운 줄 알아. 나를 두 번 속여, 나에 수치. 3 번 나를 속여, EJB를.

   일부는 Spring이 독점적이라고 주장 할 것입니다. 필자는 JavaEE 스펙의 벤더 구현이 독점적 인 것처럼 보였다고 주장 할 것이다.

   최근에 JBoss에서 Weblogic으로 많은 Java 응용 프로그램을 이전 한 주요 전환을 경험했습니다. JPA, EJB 및 JSF를 사용하는 모든 응용 프로그램은 포트 재앙이었습니다. 모든 스프링 / 하이버 네이트 응용 프로그램은 필요없는 모든 라이브러리가 있었기 때문에 제로 수정으로 이식되었습니다. appserver 간의 JPA, EJB 및 JSF 해석의 미묘한 차이로 인해 영원히 수정해야하는 모든 종류의 불쾌한 버그가 발생했습니다. JNDI 이름 지정과 같은 단순한 것조차 AppServer간에 완전히 다릅니다.

   Spring은 구현입니다. JavaEE는 사양입니다. 그것은 큰 차이입니다. 사양이 100 % 기밀이 유지되고 공급 업체가 해당 사양을 구현하는 방식에서 전혀 흔들리지 않는 공간을 제공하는 경우 사양을 사용하는 것을 선호합니다. 그러나 JavaEE 스펙은 결코 그런 적이 없습니다. 어쩌면 JavaEE6의 기밀성이 더 좋을까요? 나는 모른다. WAR에서 패키지 할 수 있고 AppServer 라이브러리에 의존 할수록 애플리케이션이 더 많이 휴대 될 수 있고, 결국 Java가 Dot-NET이 아닌 이유입니다.

   사양이 기밀 인 경우에도 모든 응용 프로그램에서 모든 기술 스택을 업그레이드하지 않고도 응용 프로그램 서버를 업그레이드 할 수 있으면 좋을 것입니다. JBoss 4.2에서 JBoss 7.0으로 업그레이드하고 싶다면 내 모든 응용 프로그램에 새로운 버전의 JSF가 미치는 영향을 고려해야합니다. Spring MVC (또는 Struts) 애플리케이션에 미치는 영향을 고려할 필요가 없습니다.

3. ==============================

   3.그건 중요하지 않아. Java EE 6는 충분히 좋으며 프로필이 있기 때문에 "무겁지"않습니다. 웹 프로필 만 사용하게됩니다.

   그건 중요하지 않아. Java EE 6는 충분히 좋으며 프로필이 있기 때문에 "무겁지"않습니다. 웹 프로필 만 사용하게됩니다.

   개인적으로 나는 봄을 선호합니다. 하지만 Java EE 6에 대한 합리적인 주장이 부족합니다. :)

   (내가 코멘트로 생각 나게 했으므로, 필요한 구성 요소에 따라 ICFfaces 및 / 또는 PrimeFaces뿐 아니라 RichFaces를 사용해 볼 수도 있습니다.)

4. ==============================

   4.최근에 나의 클라이언트 할당 중 하나는 스프링 스택 대 사용자 정의 프레임 워크 스택을 Java EE 표준과 비교하는 것을 포함했습니다. 한 달간의 평가와 프로토 타이핑을 통해 나는 행복하지 않았지만 Java EE 6 기능 세트로 날아갔습니다. 2011 년에 새로운 "엔터프라이즈"프로젝트 아키텍처가 나오면 Java EE 6과 Seam 3 또는 곧 출시 될 Apache JSR299 확장 프로젝트와 같은 잠재적 확장을 사용할 것입니다. Java EE 6 Architecture는 능률적이며 지난 수년간 발전한 많은 오픈 소스 아이디어를 최대한 활용했습니다.

   최근에 나의 클라이언트 할당 중 하나는 스프링 스택 대 사용자 정의 프레임 워크 스택을 Java EE 표준과 비교하는 것을 포함했습니다. 한 달간의 평가와 프로토 타이핑을 통해 나는 행복하지 않았지만 Java EE 6 기능 세트로 날아갔습니다. 2011 년에 새로운 "엔터프라이즈"프로젝트 아키텍처가 나오면 Java EE 6과 Seam 3 또는 곧 출시 될 Apache JSR299 확장 프로젝트와 같은 잠재적 확장을 사용할 것입니다. Java EE 6 Architecture는 능률적이며 지난 수년간 발전한 많은 오픈 소스 아이디어를 최대한 활용했습니다.

   이벤트 관리, 컨텍스트 및 DI, 인터셉터, 데코레이터, RESTful 웹 서비스, 임베디드 컨테이너를 사용한 통합 테스트, 보안 등의 기능을 즉시 사용할 수 있습니다.

   Java EE 6의 주요 개념을 설명하는 블로그에서 유용한 정보를 얻을 수 있습니다.

   물론, 프레임 워크를 선택하기위한 어렵고 빠른 규칙은 없습니다. Java EE 6은 풍부한 대화 세션 상태를 필요로하지 않는보다 단순한 "웹 사이트"를 위해 부풀려 질 수 있습니다. Grails 나 Play를 선택할 수도 있습니다! 뼈대. 하지만 대화식 웹 응용 프로그램의 경우 Java EE 6이 왜 적합하지 않은지에 대한 더 나은 주장을 볼 수 없습니다.

5. ==============================

   5.자, 잠시 후 스택에 대한 경험이 있습니다.

   자, 잠시 후 스택에 대한 경험이 있습니다.

   내 colclusions 위치 :

6. ==============================

   6.Adam Bien의 Enterprise Java에 대한 미래를 읽으십시오 ... 동전의 양면을 얻기위한 주석을 포함하여 Clear (Java EE와 Spring / Vice Versa의 유무)입니다. 나는 여러 가지 이유로 봄을 선택할 것이고, 그 중 하나는 다음과 같다 (게시물에서 주석 중 하나를 재현)

   Adam Bien의 Enterprise Java에 대한 미래를 읽으십시오 ... 동전의 양면을 얻기위한 주석을 포함하여 Clear (Java EE와 Spring / Vice Versa의 유무)입니다. 나는 여러 가지 이유로 봄을 선택할 것이고, 그 중 하나는 다음과 같다 (게시물에서 주석 중 하나를 재현)

   '당신이 말하는 Java EE 6 서버가 확실하지 않습니다. Glassfish 인증 및 TMAX JEUS가 있습니다. Java EE 6 호환 버전의 WebSphere, WebLogic, JBoss 등이 생산 될 때까지는 상당한 시간이 걸릴 것입니다 (읽기 : 년). 실제 응용 프로그램에 사용할 수 있습니다. Spring 3은 자바 1.5와 J2EE 1.4를 필요로하므로 거의 모든 환경에서 쉽게 사용할 수 있습니다.

7. ==============================

   7.제 의견은 다른 사람들이 언급하지 않은 것에 근거합니다. 즉, 제 작품의 코드는 수십 년 동안 (문자 그대로) 사는 경향이 있으며, 따라서 유지 보수는 우리에게 매우 중요합니다. 자체 코드 및 우리가 사용하는 라이브러리의 유지 보수. 우리가 통제하는 자체 코드이지만, 우리가 사용하는 라이브러리가 위에서 언급 한 수십 년 또는 그 이상에 다른 사람들에 의해 유지되는 것이 우리의 관심사입니다.

   제 의견은 다른 사람들이 언급하지 않은 것에 근거합니다. 즉, 제 작품의 코드는 수십 년 동안 (문자 그대로) 사는 경향이 있으며, 따라서 유지 보수는 우리에게 매우 중요합니다. 자체 코드 및 우리가 사용하는 라이브러리의 유지 보수. 우리가 통제하는 자체 코드이지만, 우리가 사용하는 라이브러리가 위에서 언급 한 수십 년 또는 그 이상에 다른 사람들에 의해 유지되는 것이 우리의 관심사입니다.

   긴 이야기를 짧게하기 위해, 나는 이것을 달성하기위한 가장 좋은 방법은 Sun 사양의 오픈 소스 구현을 원시 JVM까지 사용하는 것이라고 결론 지었다.

   오픈 소스 구현 중 Apache Jakarta는 라이브러리를 유지 관리하는 것으로 입증되었으며, 최근 Sun은 Glassfish v3의 고품질 구현을 제작하는 데 많은 노력을 기울였습니다. 어쨌든 모든 모듈에 대한 소스도 있으므로 모든 모듈이 실패 할 경우 모듈을 직접 유지 관리 할 수 ​​있습니다.

   Sun 사양은 일반적으로 사양을 준수하는 구현을 쉽게 교환 할 수 있다는 의미로 매우 엄격합니다. 서블릿 컨테이너를 살펴보십시오.

   이 특별한 경우에는 JavaServer Faces가 Java EE 6의 일부이기 때문에 JavaServer Faces를 살펴 보는 것이 좋습니다. 이는 매우 오랫동안 사용 가능하고 유지 관리된다는 것을 의미합니다. 그런 다음 MyFaces Tomahawk를 사용하여 유용한 추가 기능을 추가하기로 결정했으며 자카르타 프로젝트입니다.

   JBoss Seam이나 다른 것들에는 아무런 문제가 없습니다. 그들의 관심이 우리에게 매우 중요한 유지 보수 문제에 덜 집중한다는 것입니다.

8. ==============================

   8.이미 Spring을 사용하고 있다면 Spring을 사용할 수 있습니다. 그러나 새 프로젝트의 경우 요점은 무엇입니까? 나는 Java EE 6 (ejb3, jsf2.0 등)과 직접 갈 것입니다.

   이미 Spring을 사용하고 있다면 Spring을 사용할 수 있습니다. 그러나 새 프로젝트의 경우 요점은 무엇입니까? 나는 Java EE 6 (ejb3, jsf2.0 등)과 직접 갈 것입니다.

   클라이언트가 Flex에서 문제가 없다면 먼저 해보십시오. BlazeDS 또는 유사 물을 사용하십시오 - mvc 없음. 해당 부분에 더 많은 시간을 할애 할 수 있지만 (서버와 클라이언트간에 데이터 교환) 양측 모두에서 모든 권한을가집니다.

   브라우저를 죽이고 싶지 않으면 Vaadin을 사용하지 마십시오. 또한 페이지가 복잡 해지면 코드를 둘러 보는 데 더 많은 시간을 할애 할 수 있습니다. 또한 사고 방식을 완전히 바꿔야하고 표준 프론트 엔드 개발에 대해 알고있는 어떤 것도 낭비 일 것입니다. HTML이나 JS를 사용할 필요가 없다는 주장은별로 의미가 없습니다. 당신이 그것을 사용하지 않더라도 당신은 여전히 ​​그것을 알아야만합니다. 결국 HTML과 JS로 렌더링됩니다. 그런 다음 디버깅을 시도하십시오 - 간단한 작업으로 며칠을 보내야합니다. 게다가 html / js를 모르는 웹 개발자는 상상할 수 없습니다.

   Java EE를 직접 사용하는 대신 사람들이 왜 모든 추상화를 시도하는지 이해할 수 없습니다.

9. ==============================

   9.왜 EJB가 2010 년에 헤비급인지에 대한 소문이 나옵니 까? 사람들이 Java EE 기술에서 업데이트되지 않는 것 같습니다. Java EE 6에서 단순화 된 방법에 놀랄 것입니다.

   왜 EJB가 2010 년에 헤비급인지에 대한 소문이 나옵니 까? 사람들이 Java EE 기술에서 업데이트되지 않는 것 같습니다. Java EE 6에서 단순화 된 방법에 놀랄 것입니다.

10. ==============================

    10.질문에 대한 답변은 프로젝트 요구 사항에 따라 다릅니다. 메시지 대기열과 같은 Java EE 기능이 필요하지 않은 경우 컨테이너 관리 글로벌 트랜잭션 등이 필요하면 tomcat + spring을 사용하십시오.

    질문에 대한 답변은 프로젝트 요구 사항에 따라 다릅니다. 메시지 대기열과 같은 Java EE 기능이 필요하지 않은 경우 컨테이너 관리 글로벌 트랜잭션 등이 필요하면 tomcat + spring을 사용하십시오.

    또한 경험에 비추어 볼 때 많은 웹 서비스 통합, 스케줄링, 메시지 대기열을 필요로하는 프로젝트는 Java EE 스택 중 일부를 사용하는 것이 가장 좋습니다. 좋은 점은 응용 프로그램 서버에서 실행되는 Java EE 모듈과 통합 할 수있는 스프링을 사용한다는 것입니다.

    Java EE 6은 이전 릴리스와 매우 다르며 모든 것을 훨씬 쉽게 만듭니다. Java EE 6는 다양한 Java 커뮤니티의 최상의 아이디어를 결합합니다. 예를 들어 Spring 프레임 워크의 Rod Johnson은 Java EE 6에서 Dependency Injection JSR을 만드는 데 적극적으로 관여했습니다. Java EE 6을 사용하는 이점은 이는 벤더 지원 등을 위해 일부 조직에서 중요 할 수있는 표준입니다.

    GlassFish v3는 Java EE 6를 지원하며 매우 가볍고 빠르게 시작됩니다. 내 개발에 glassfish v3를 사용하고 있으며 구성하기가 정말 쉽습니다. 그래픽을 사용하여 서버를 관리 할 수있는 매우 사용하기 쉬운 관리 콘솔이 제공됩니다.

    GlassfishV3 및 JSF 2를 사용하는 경우 Java EE 6의 CDI 기능을 활용할 수 있으므로 JSF에서 대화 형 페이지 (예 : 마법사와 같은)를 쉽게 만들 수 있습니다.

    그렇지만 Java EE 6을 사용하려면 새로운 API를 배우는 것이 필요합니다. 가능한 시간대에 따라 귀하를위한 최선의 선택이 아닐 수도 있습니다. Tomcat은 여러 세대 동안 사용되어 왔으며 많은 웹 프로젝트에서 Tomcat + Spring 조합이 채택되어 많은 문서 / 포럼이 주위에 있습니다.

11. ==============================

    11.Spring과 Java EE 6 모두에서 일해 왔습니다. 제 경험으로 말할 수있는 것은 오래된 JSP 또는 독점적 인 Flex를 사용한다면 Spring을 사용하는 것이 안전하다는 것입니다.

    Spring과 Java EE 6 모두에서 일해 왔습니다. 제 경험으로 말할 수있는 것은 오래된 JSP 또는 독점적 인 Flex를 사용한다면 Spring을 사용하는 것이 안전하다는 것입니다.

    그러나 JSF로 전환하려면 Java EE 6로 전환해야합니다. Java EE 6에서는 Facelets 및 표준화 된 스크립트 라이브러리 및 구성 요소 라이브러리로 이동합니다. 스크립트 비 호환성 및 구성 요소 라이브러리 행렬이 없어졌습니다.

    Spring MVC에 관해서는 프로젝트가 너무 커지지 않는 한 좋다. 거대한 엔터프라이즈 애플리케이션이 Java EE 6을 고집한다면 그것은 컴포넌트 라이브러리와 리소스 번들을 질서 정연하게 유지할 수있는 유일한 방법이기 때문입니다.

12. ==============================

    12.Java EE 풀 스택이 필요한 경우 GlassFish 3.1을 사용하는 것이 좋습니다. 일부 Java EE 6 (JBoss 6, WebLogic 10.3.4)의 일부 또는 전체를 구현하는 다른 Java EE 컨테이너에 비해 매우 빨리 시작되며, 재배포에는 몇 초가 걸리고 거의 모든 것이 구성을 통해 규칙을 통해 수행 될 수 있으므로 매우 친숙합니다.

    Java EE 풀 스택이 필요한 경우 GlassFish 3.1을 사용하는 것이 좋습니다. 일부 Java EE 6 (JBoss 6, WebLogic 10.3.4)의 일부 또는 전체를 구현하는 다른 Java EE 컨테이너에 비해 매우 빨리 시작되며, 재배포에는 몇 초가 걸리고 거의 모든 것이 구성을 통해 규칙을 통해 수행 될 수 있으므로 매우 친숙합니다.

    "Light"를 원한다면 원하는 기능으로 Apache Tomcat 7.x를 사용자 정의 할 수 있습니다. 나는 다음 라이브러리들과 많이 썼다. 용접 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - 리소스 로컬 트랜잭션 만 JSF 2.x (모하라) RichFaces 4.0 BIRT 런타임

    지난 10 년 동안 Java EE 개발자였습니다 (초기 EJB, JSF 및 웹 기술로 어려움을 겪었습니다), Java EE 6은 매우 쉽고, 잘 결합되어 있으며, 현재 하드웨어가 원활하게 실행되므로 Spring이 더 이상 유효하지 않은 원래의 이유가 있습니다.

13. ==============================

    13.나는 여전히 봄을 좋아할 것입니다.

    나는 여전히 봄을 좋아할 것입니다.

    JSF를 전달할 것입니다. 나는 그것이 죽은 기술이라고 생각한다. 스프링 MVC가 더 나은 대안이 될 것이다. 그렇다면 Flex. 계약 첫 번째 XML 서비스 측면에서 생각해 보면 UI에서 백엔드를 완전히 분리 할 수 ​​있습니다.

14. ==============================

    14.glassfish v3와 Weld가 더 성숙해질 때까지 기다릴 수 없다면 Spring + Tomcat을 권하고 싶습니다. 현재 CDI 가능 응용 프로그램과 함께 glassfish를 실행할 때 메모리 소비 / cpu로드에 몇 가지 문제가 있습니다.

    glassfish v3와 Weld가 더 성숙해질 때까지 기다릴 수 없다면 Spring + Tomcat을 권하고 싶습니다. 현재 CDI 가능 응용 프로그램과 함께 glassfish를 실행할 때 메모리 소비 / cpu로드에 몇 가지 문제가 있습니다.

15. ==============================

    15.모든 것을 읽지는 않았지만 이제는 Java EE 6에서 EJB3를 사용할 수 있으므로 Tomcat에서 EJB3를 사용할 수 있다는 것을 알았습니다 (필자는 생각합니다).

    모든 것을 읽지는 않았지만 이제는 Java EE 6에서 EJB3를 사용할 수 있으므로 Tomcat에서 EJB3를 사용할 수 있다는 것을 알았습니다 (필자는 생각합니다).

16. ==============================

    16.나는 Tomcat을 봄용으로 추천했다 :

    나는 Tomcat을 봄용으로 추천했다 :

    그것은 당신이 어떤 중량급 처리도 필요 없기 때문에 Tomcat을 선택하는 좋은 선택입니다

from https://stackoverflow.com/questions/2499323/java-ee-6-vs-spring-3-stack by cc-by-sa and MIT license