지금 새 프로젝트를 시작하고 있습니다. 기술을 선택해야합니다. 가벼운 것이 필요하므로 EJB 또는 Seam이 없습니다. 반면에 JPA (Hibernate 또는 대안)와 IceFaces가있는 JSF가 필요합니다.
Tomcat에 배포 된 Spring 3의 이러한 스택이 좋은 선택이라고 생각하십니까? 아니면 Java EE 6 웹 애플리케이션이 더 좋을까요? Java EE 6이 아직 잘 문서화되지 않은 새로운 기술인 것이 두렵습니다. Tomcat은 Glassfish 3보다 유지 관리가 더 쉬운 것 같습니다.
당신의 의견은 무엇입니까? 경험이 있습니까?
답변
가벼운 것이 필요하므로 EJB 또는 Seam이 없습니다.
EJB3 이후 EJB를 무겁게 만드는 이유를 설명해 주시겠습니까? 우리가 2004 년이 아니라는 사실을 알고 있습니까? 나는 빛에 대한 당신의 정의와 당신의 주장 을 읽고 싶습니다 (그리고 제가 몇 가지 확실한 말을 할 것이라 확신하기 때문에 기꺼이 제 답변을 업데이트하겠습니다).
반면에 JPA (Hibernate 또는 대안)와 IceFaces가있는 JSF가 필요합니다.
JSF 2.0, JPA 2.0, Bean 유효성 검사, EJB 3.1 Lite, CDI 등을 포함하는 Java EE 6 웹 프로필은이를 위해 완벽하며 GlassFish v3 웹 프로필 을 사용하여 Java EE 6 웹 프로필로 빌드 된 응용 프로그램을 실행할 수 있습니다. .
Tomcat에 배포 된 Spring 3의 이러한 스택이 좋은 선택이라고 생각하십니까? 아니면 Java EE 6 웹 애플리케이션이 더 좋을까요?
글쎄요, 저는 독점 컨테이너 (Spring) 보다는 비 독점 플랫폼 (Java EE) 에서 내 코드를 실행하는 아이디어를 좋아합니다 . 그리고 저는 Java EE 6이 충분히 좋다고 생각합니다 (그리고 이것은 완곡 어법, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI 킥 엉덩이입니다). 내가 JSF 회의론자 였지만 다시 한 번 살펴 보았고 CDI가 포함 된 JSF 2.0은 너무 다르기 때문에 비교할 수도 없습니다. 그리고 CDI를 보지 않았다면 그것이 흔들린다 고 말씀 드리겠습니다.
Java EE 6이 아직 잘 문서화되지 않은 새로운 기술인 것이 두렵습니다.
Java EE는 나에게 꽤 잘 문서화되어 있습니다. 이것은 무료 청구처럼 들립니다. 그리고 저를 믿거 나 말거나 저는 Spring이 복잡해지고 Java EE가 쉬워지는 것을 발견하기 시작합니다.
Tomcat은 Glassfish 3보다 유지 관리가 더 쉬운 것 같습니다.
뭔가 해봤 어? 특별한 문제가 있었습니까? 다시 말하지만 이것은 무료 청구처럼 들립니다.
답변
JavaEE6를 사용하지 않았습니다.
그러나 저는 JavaEE 및 EJB의 모든 이전 버전에 의해 충분히 심하게 구타를 당하여 법적 표준이 아닌 사실상의 표준으로 자리 잡을 때까지 신뢰하지 않을 것입니다. 현재 Spring은 여전히 사실상의 표준입니다.
한 번만 속여, 부끄러워. 날 두 번 속이고 부끄러워 세 번 속여, EJB.
일부는 Spring이 독점적이라고 주장 할 것입니다. 저는 JavaEE 사양의 공급 업체 구현이 그 이상은 아니지만 독점적이라고 주장합니다.
저는 최근에 JBoss에서 Weblogic으로 많은 Java 애플리케이션을 이동하는 주요 변환을 거쳤습니다. 모든 Spring / Hibernate 앱은 필요한 모든 라이브러리가 내장되어 있기 때문에 수정없이 이식되었습니다. JPA와 EJB 및 JSF를 사용하는 모든 앱은 이식에 재앙이었습니다. 애플리케이션 서버 간의 JPA, EJB 및 JSF 해석의 미묘한 차이로 인해 영구적으로 수정하는 데 필요한 모든 종류의 불쾌한 버그가 발생했습니다. JNDI 이름 지정과 같은 단순한 것조차도 AppServer마다 완전히 달랐습니다.
Spring은 구현입니다. JavaEE는 사양입니다. 그것은 엄청난 차이입니다. 사양이 100 % 밀폐되어 있고 공급 업체가 해당 사양을 구현하는 방식에 흔들림이 전혀없는 경우 사양을 사용하는 것이 좋습니다. 그러나 JavaEE 사양은 결코 그렇지 않습니다. JavaEE6가 더 밀폐 된 것일까 요? 모르겠어요. WAR에서 더 많이 패키징 할 수 있고 AppServer 라이브러리에 덜 의존할수록 응용 프로그램의 이식성이 향상되며 결국 Dot-NET이 아닌 Java를 사용하는 이유입니다.
사양이 완벽하더라도 모든 애플리케이션의 모든 기술 스택을 업그레이드하지 않고도 애플리케이션 서버를 업그레이드 할 수 있다면 좋을 것입니다. JBoss 4.2에서 JBoss 7.0으로 업그레이드하려면 최신 버전의 JSF가 모든 애플리케이션에 미치는 영향을 고려해야합니다. Spring-MVC (또는 Struts) 애플리케이션에 미치는 영향을 고려할 필요가 없습니다.
답변
상관 없습니다. Java EE 6은 충분하며 거기에있는 프로필 때문에 “무거운”것이 아닙니다. 웹 프로필 만 사용하게됩니다.
개인적으로 저는 Spring을 선호합니다. 하지만 Java EE 6에 대한 합리적인 주장이 부족합니다. 🙂
(댓글을 통해 상기했듯이- 필요한 구성 요소에 따라 RichFaces , ICEfaces 및 / 또는 PrimeFaces 를 사용해 볼 수 있습니다).
답변
최근에 내 클라이언트 할당 중 하나는 Spring Stack Vs Custom 프레임 워크 스택 Vs a Java EE 표준 평가와 관련이 있습니다. 한 달 간의 평가와 프로토 타이핑을 마친 후 저는 행복 할뿐만 아니라 Java EE 6 기능 세트에 놀랐습니다. 2011 년 이후의 새로운 “엔터프라이즈”프로젝트 아키텍처의 경우 Java EE 6 및 Seam 3 또는 곧 출시 될 Apache JSR299 확장 프로젝트와 같은 잠재적 확장을 사용합니다. Java EE 6 아키텍처는 간소화되었으며 지난 몇 년 동안 발전해온 많은 오픈 소스 아이디어 중 최고의 아이디어를 통합합니다.
이벤트 관리, 컨텍스트 및 DI, 인터셉터, 데코레이터, RESTful 웹 서비스, 내장형 컨테이너를 사용한 통합 테스트, 보안 등의 기능을 즉시 고려하십시오.
내 결과의 대부분은 유용 할 수있는 Java EE 6의 주요 개념을 설명하는 내 블로그에 게시됩니다 .
물론 프레임 워크를 선택하는 데있어 엄격하고 빠른 규칙은 없습니다. Java EE 6은 풍부한 대화 세션 상태를 필요로하지 않는 단순한 “웹 사이트”에 적합합니다. Grails 또는 Play를 선택하는 것이 좋습니다! 뼈대. 그러나 대화 형 웹 애플리케이션의 경우 Java EE 6이 적합하지 않은 이유를 더 잘 알 수 없습니다.
답변
이제 얼마 후 스택에 대한 경험이 있습니다.
- Java EE 5 + Seam + GraniteDS + Flex
- Spring 3 + Vaadin (GWT)
- Spring 3 + JSF 2.0 (PrimeFaces)
내 공모는 다음과 같습니다.
- Spring 3는 Seam (거의 Java EE 6)보다 훨씬 간단하며 Tomcat 및 Jetty에서 실행됩니다! (Maven 플러그인을 사용한 개발을위한 Jetty는 헛소리입니다).
- 저는 Flex를 좋아합니다 (실제로 저는 Flex 개발자 였기 때문에 편견이 있습니다). 풍부한 인터페이스가 필요하고 FlashBuilder를 구입할 수 있다면 이것을 사용하지만 Spring + GraniteDS 또는 BlazeDs 백엔드를 사용하십시오. FlashBuilder를 구입할 수 없다면 시간을 낭비하지 마십시오.
- Vaadin은 훌륭합니다!. 개발 프로세스는 Flex보다 간단하지만 HTML 혼란없이 쉽게 풍부한 애플리케이션을 만들 수 있습니다. 단일 JS 라인을 작성하지 않을 것입니다. CSS가 필요합니다 (Flex에서도 필요합니다). 따라서 응용 프로그램 인터페이스가 데스크톱 응용 프로그램처럼 작동하고 Flex를 사용할 수 없거나 사용하지 않으려는 경우 Vaadin을 사용하십시오. 경고! Vaadin은 브라우저에 대한 큰 JS 오버 헤드를 가지고 있습니다.
- 더 간단한 웹 사이트와 같은 애플리케이션을 만드는 경우 JSF2.0 (위와 같이 스프링 백엔드 포함)을 사용합니다. 당신은 HTML과 싸워야 할 것입니다 (나는 싫어합니다) 그리고 풍부한 인터페이스를 만드는 것은 Vaadin (특히 레이아웃)보다 어려울 것입니다. 느린 브라우저 / 컴퓨터를위한 가벼운 HTML을 얻을 수 있습니다. 저는 PrimeFaces를 좋아합니다-쉽고 잘 문서화되어 있습니다. 두 번째 장소는 IceFaces입니다.
- HTML (브라우저에 맞는 엔터프라이즈 애플리케이션을 만드는 대신)에 생명을 불어 넣어야하는 웹 사이트 (웹 애플리케이션이 아님)를 만드는 경우 Wicket (구성 요소 기반을 선호하는 경우 풀 태도) 또는 SpringMVC (템플릿 기반을 선호하는 경우)를 사용합니다. , 푸시 자세) 또는 그냥 Play! 뼈대. 풍부한 데이터 기반 구성 요소를 만드는 것은 훨씬 더 어렵지만 HTML의 각 태그를 제어 할 수 있습니다 (HTML / 그래픽 디자이너가 좋아할 것입니다).
답변
Adam Bien의 Future Of Enterprise Java … Is Clear (Java EE with / without Spring and Vice Versa)를 읽어 보세요. 나는 몇 가지 이유로 Spring을 선택할 것이며 다음은 그중 하나입니다 (게시물에서 댓글 중 하나를 재현).
‘어떤 Java EE 6 서버에 대해 이야기하고 있는지 잘 모르겠습니다. Glassfish 인증 및 TMAX JEUS가 있습니다. Java EE 6 호환 버전의 WebSphere, WebLogic, JBoss 등이 생산되고 실제 응용 프로그램에 사용될 수 있으려면 꽤 오랜 시간이 걸립니다 (읽기 : 몇 년). Spring 3에는 Java 1.5 및 J2EE 1.4 만 필요하므로 거의 모든 환경에서 쉽게 사용할 수 있습니다.
답변
내 의견은 다른 사람이 언급하지 않은 것, 즉 내 작업의 코드가 수십 년 동안 (문자 그대로) 유지되는 경향이 있으므로 유지 관리가 우리에게 매우 중요하다는 점에 기반합니다. 우리 자신의 코드와 우리가 사용하는 라이브러리의 유지 관리. 우리가 제어하는 우리 자신의 코드이지만 우리가 사용하는 라이브러리가 위에서 언급 한 수십 년 이상 동안 다른 사람들 이 유지 관리하는 것이 우리의 관심사입니다 .
간단히 말해서,이를 달성하는 가장 좋은 방법은 원시 JVM까지 Sun 사양의 오픈 소스 구현을 사용하는 것이라고 결론지었습니다.
오픈 소스 구현 중 Apache Jakarta는 라이브러리를 유지하는 것으로 입증되었으며 최근 Sun은 Glassfish v3에 대한 고품질 구현을 생성하는 데 많은 작업을 수행했습니다. 어쨌든 우리는 또한 모든 모듈의 소스를 가지고 있으므로 다른 모든 모듈이 실패하면 우리가 직접 유지할 수 있습니다.
Sun 사양은 일반적으로 사양을 준수하는 구현이 쉽게 교환 될 수 있다는 것을 의미하는 매우 엄격한 의미입니다. 서블릿 컨테이너를 살펴보십시오.
이 특별한 경우에는 Java EE 6의 일부이기 때문에 JavaServer Faces를 살펴 보는 것이 좋습니다. 이는 매우 오랫동안 사용할 수 있고 유지 관리 될 것임을 의미합니다. 그런 다음 MyFaces Tomahawk를 사용하여 유용한 추가 기능을 제공하기로 선택했으며 이는 자카르타 프로젝트입니다.
JBoss Seam이나 다른 사람들에게는 잘못된 것이 없습니다. 그들의 초점은 우리에게 매우 중요한 유지 보수 문제에 덜 집중되어 있다는 것입니다.
