Java EE 6 대스프링 3 스택
저는 지금 새로운 프로젝트를 시작하고 있습니다.나는 기술을 선택해야 한다.가벼운 게 필요하니까 EJB나 심은 안 돼요.한편, JPA(Hibernate or alternative)와 JSF with IceFaces가 필요합니다.
Tomcat에 배치된 Spring 3 위의 이러한 스택이 적절한 선택이라고 생각하십니까?아니면 Java EE 6 웹 어플리케이션이 더 나을까요?유감스럽게도 Java EE 6은 아직 제대로 문서화되어 있지 않은 새로운 기술입니다.Glassfish 3보다 Tomcat이 유지보수가 쉬워 보입니다.
당신 생각은 어떻습니까?당신은 어떤 경험이 있습니까?
가벼운 게 필요하니까 EJB나 심은 안 돼요.
EJB3 이후 EJB가 무거운 이유를 설명해 주시겠습니까?우리가 더 이상 2004년이 아니라는 걸 알고 있니?빛에 대한 당신의 정의와 당신의 주장을 읽고 싶습니다(그리고 저는 제가 몇 가지 확실한 말을 할 수 있다고 확신하기 때문에 기꺼이 제 답변을 업데이트하겠습니다).
한편, JPA(Hibernate or alternative)와 JSF with IceFaces가 필요합니다.
JSF 2.0, JPA 2.0, Bean Validation, 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 kick ass 등).JSF 회의론자였지만 다시 살펴봤는데 CDI를 사용하는 JSF 2.0은 비교조차 할 수 없을 정도로 다릅니다.CDI를 보지 않으셨다면 정말 대단하다고 말씀드리겠습니다.
유감스럽게도 Java EE 6은 아직 제대로 문서화되어 있지 않은 새로운 기술입니다.
자바 EE는 꽤 잘 문서화되어 있는 것 같습니다.무료 청구처럼 들리네요.그리고 믿거나 말거나, Java EE가 쉬워지는 동안 봄은 복잡해지기 시작합니다.
Glassfish 3보다 Tomcat이 유지보수가 쉬워 보입니다.
뭐 좀 해봤어?당신은 특별한 문제에 직면했습니까?다시 말하지만, 이것은 무료 청구처럼 들린다.
JavaEE6를 사용한 적이 없습니다.
하지만, 저는 JavaEE와 EJB의 이전 버전에 의해 충분히 심하게 두들겨 맞았기 때문에, 그것이 단지 법률상의 표준이 아닌 사실상의 표준으로 자리잡을 때까지는 신뢰하지 않을 것입니다.현재도 봄은 사실상의 기준이다.
날 한 번 속여봐, 부끄러운 줄 알아라.날 두 번 속이면 창피한 줄 알아라날 세 번 속여봐, EJB.
일부는 봄은 전유물이라고 주장할 것이다.JavaEE 사양의 벤더 실장은, 그 이상은 아니더라도, 전유물이라고 생각합니다.
저는 최근에 Java 어플리케이션의 많은 부분을 JBoss에서 Weblogic으로 이행하는 큰 전환을 했습니다.Spring/Hibernate 앱은 필요한 라이브러리를 모두 내장하고 있기 때문에 수정이 전혀 이루어지지 않았습니다.JPA, EJB, JSF를 사용하는 모든 앱은 포트에서 재난이었습니다.앱 서버 간의 JPA, EJB, JSF 해석의 미묘한 차이로 인해 모든 종류의 고약한 버그가 수정되는 데 오랜 시간이 걸렸습니다.JNDI 이름처럼 간단한 것도 AppServers 간에 완전히 달랐습니다.
봄은 구현이다.JavaEE는 사양입니다.그것은 엄청난 차이입니다.사양이 100% 기밀이고 벤더가 그 사양의 실장 방법에 전혀 여유가 없는 경우, 저는 사양을 사용하는 것을 선호합니다.그러나 JavaEE 사양은 그렇지 않습니다.JavaEE6가 좀 더 밀폐되어 있지 않을까요?몰라.WAR에서 패키징할 수 있는 것이 많아지고 AppServer 라이브러리에 의존하지 않을수록 어플리케이션의 휴대성이 높아집니다.그것이 바로 제가 Dot-NET이 아닌 Java를 사용하는 이유입니다.
사양이 완전하다고 해도, 모든 애플리케이션의 모든 테크놀로지 스택을 업그레이드하지 않고 앱 서버를 업그레이드할 수 있으면 좋겠습니다.JBoss 4.2에서JBoss 7.0으로 업그레이드하려면 새로운 버전의 JSF가 모든 애플리케이션에 미치는 영향을 고려해야 합니다.Spring-MVC(또는 Struts) 어플리케이션에 대한 영향을 고려할 필요가 없습니다.
그건 중요하지 않아.Java EE 6이면 충분하고, 프로파일이 있기 때문에 "무거운" 것이 아니라 웹 프로파일을 사용할 뿐입니다.
저는 개인적으로 봄을 더 좋아해요.하지만 Java EE 6에 대한 합리적인 주장은 이제 다 되어가고 있습니다.
(필요한 컴포넌트에 따라서는 RichFaces와 ICEFaces 및 PrimeFaces를 사용해 보는 것이 좋을지도 모릅니다.)
최근 고객 과제 중 하나는 Spring Stack과 Custom Framework Stack과 Java EE Standard의 평가였습니다.평가와 프로토타이핑을 한 달 동안 진행한 결과, 저는 Java EE 6 기능 세트에 만족했을 뿐만 아니라 매우 기뻤습니다.2011년 이후 새로운 "엔터프라이즈" 프로젝트 아키텍처의 경우 Java EE 6 및 Seam 3 또는 향후 Apache JSR299 확장 프로젝트와 같은 잠재적 확장을 사용합니다.Java EE 6 Architecture는 합리화되어 있으며 지난 몇 년 동안 발전한 많은 오픈 소스 아이디어 중 최고의 것을 통합하고 있습니다.
Event Management, Contexts and DI, Interceptors, Decorators, RESTful Webservices, 임베디드 가능한 컨테이너와의 통합 테스트, Security 등의 기능을 즉시 고려해 보십시오.
제 결과의 대부분은 도움이 될 만한 Java EE 6의 주요 개념을 설명하는 블로그에 게재되어 있습니다.
물론 틀을 고르는 데 있어 딱딱하고 빠른 규칙은 없다.Java EE 6은 풍부한 대화 세션 상태를 필요로 하지 않는 단순한 "웹 사이트"의 경우 매우 비대해질 수 있습니다.차라리 Grails나 Play를 고르세요!프레임워크그러나 대화형 웹 어플리케이션의 경우, 왜 Java EE 6이 적합하지 않은지에 대한 더 나은 주장은 있을 수 없습니다.
시간이 좀 지난 후 스택에 대한 경험이 생겼습니다.
- Java EE 5 + 심 + 화강암DS + Flex
- 스프링 3 + Vaadin (GWT 상)
- 스프링 3 + JSF 2.0 (프라임페이스)
결론은 다음과 같습니다.
- Spring 3은 Seam(거의 Java EE 6)보다 훨씬 심플하고 Tomcat과 Jetty에서 실행됩니다(메이븐 플러그인을 사용한 개발을 위한 Jetty는 매우 중요합니다).
- Flex를 매우 좋아합니다(실제로 오랫동안 Flex 개발자로 일했기 때문에 편견이 있습니다). 풍부한 인터페이스가 필요하고 FlashBuilder를 구입할 수 있다면 이 제품을 사용하십시오. 단, 이 제품은 Spring + Granchamnate를 사용하십시오.DS 또는 BlazeDs 백엔드FlashBuilder를 구입할 수 없는 경우에도 시간을 낭비하지 마십시오.
- 바딘은 대단해!개발 프로세스는 Flex보다 간단하지만 HTML의 혼란 없이 리치 애플리케이션을 쉽게 만들 수 있습니다.싱글 JS 행은 쓰지 않습니다.CSS가 필요합니다(Flex에서는 CSS도 필요합니다).따라서 애플리케이션 인터페이스가 데스크톱 애플리케이션처럼 작동하며 Flex를 사용할 수 없는 경우(또는 사용할 수 없는 경우) Vaadin을 사용하십시오.경고!Vaadin에는 브라우저용 JS 오버헤드가 큽니다.
- 보다 심플한 Web 사이트와 같은 애플리케이션을 작성하는 경우는, JSF2.0(상기와 같이 스프링 백엔드를 사용)을 사용합니다.HTML로 싸워야 합니다(싫습니다). 풍부한 인터페이스를 만드는 것은 Vaadin(특히 레이아웃)보다 어렵습니다.느린 브라우저/컴퓨터를 위한 경량 HTML을 얻을 수 있습니다.저는 Prime Faces를 좋아합니다.간단하고 문서화되어 있습니다.2위는 IceFaces입니다.
- HTML에 생명을 불어넣을 필요가 있는 웹 사이트(웹 어플리케이션이 아님)를 작성하는 경우(브라우저에 맞는 엔터프라이즈응용 프로그램을 작성하는 대신), Wicket(컴포넌트 베이스로 하는 경우) 또는 SpringMVC(템플릿 베이스로 하는 경우 푸시 자세) 또는 Play! 프레임워크만 사용합니다.풍부한 데이터 기반의 컴포넌트를 작성하는 것은 매우 어렵지만 HTML의 각 태그를 제어할 수 있습니다(HTML/Graphics 설계자가 매우 좋아합니다).
Adam Bien의 엔터프라이즈 Java 미래 읽기...Is Clear(스프링 유무와 그 반대의 경우)에는 코인의 양면을 취득하는 코멘트가 포함되어 있습니다.몇 가지 이유로 봄을 선택하고, 그 중 하나가 팔로잉입니다(투고 코멘트 중 하나 재현).
'어느 Java EE 6 서버를 말씀하시는 건지 잘 모르겠습니다.Glassfish 인증과 TMAX JEUS가 있습니다.Java EE 6 호환 버전의 WebSphere, WebLogic, JBoss 등이 실제 가동되고 실제 애플리케이션에 사용할 수 있게 될 때까지 상당한 시간(읽기: 년)이 걸립니다.Spring 3에는 Java 1.5 및 J2EE 1.4만 있으면 거의 모든 환경에서 쉽게 사용할 수 있습니다.'
제 의견은 다른 사람이 언급하지 않은 것, 즉 제 직장에서의 코드는 수십 년(리터럴) 동안 존속하는 경향이 있기 때문에 유지보수가 매우 중요하다고 생각합니다.자체 코드와 우리가 사용하는 라이브러리의 유지 보수.우리가 통제하는 자체 코드는 우리가 사용하는 라이브러리가 위에서 언급한 수십 년 또는 그 이상 동안 다른 사람들에 의해 유지되는 것이 우리의 이익에 부합합니다.
요약하자면, 이를 실현하는 가장 좋은 방법은 Sun 사양의 오픈 소스 구현을 사용하여 원시 JVM에 이르는 것이라고 결론지었습니다.
오픈 소스 구현 중 Apache Jakarta는 라이브러리를 유지하는 것이 입증되었으며, 최근 Sun은 Glassfish v3용 고품질 구현을 제작하는 데 많은 노력을 기울이고 있습니다.어느 경우든 모든 모듈의 소스도 있기 때문에 다른 모든 모듈에 장애가 발생했을 경우 델이 직접 관리할 수 있습니다.
Sun 사양은 일반적으로 매우 엄격한 것으로, 사양에 준거한 실장은 쉽게 교환할 수 있습니다.서블릿 컨테이너를 한 번 보세요.
이 경우 Java Server Faces는 Java EE 6의 일부이기 때문에 매우 오랫동안 사용할 수 있고 유지보수가 가능합니다.그 후 MyFaces Tomahawk로 증강하는 것을 선택했습니다.이것은 자카르타 프로젝트입니다.
JBoss Seam 등에는 문제가 없습니다.우리에게 매우 중요한 것은 그들이 유지 보수 문제에 덜 집중하고 있다는 것입니다.
스프링을 이미 가지고 있다면 사용할 수 있지만, 새로운 프로젝트는 무슨 의미가 있나요?Java EE 6(ejb3, jsf2.0 등)을 직접 사용합니다.
고객이 Flex에 문제가 없다면 그렇게 하십시오.Blaze 사용DS 또는 유사 - MVC 없음그 부분에 더 많은 시간을 할애할 수 있지만(서버와 클라이언트 간에 데이터를 교환할 수 있습니다), 양쪽에서 완전한 제어를 할 수 있습니다.
브라우저를 종료하지 않는 한 Vaadin을 사용하지 마십시오.또, 페이지가 복잡해지면, 코드를 이해하는데 더 많은 시간을 들일 수 있습니다.또한 사고방식을 완전히 바꿔야 하며 표준 프런트 엔드 개발에 대해 알고 있는 모든 것이 낭비됩니다.HTML이나 JS를 사용할 필요가 없다는 주장은 별로 말이 되지 않습니다.안 써도 알아둬야 돼요.최종적으로 HTML과 JS로 렌더링됩니다.그런 다음 디버깅을 시도합니다.간단한 일을 할 수 있는 날이 며칠인지 확인합니다.또한 html/js를 모르는 웹 개발자는 상상할 수 없습니다.
나는 왜 사람들이 Java EE를 직접 사용하는 대신 이러한 추상적인 것들을 시도하는지 이해할 수 없다.
EJB가 2010년에 헤비급이라는 소문이 아직도 나오는 이유는 무엇입니까?Java EE 기술에서 사람들이 업데이트되지 않는 것 같습니다.한 번 사용해 보세요.Java EE 6에서는, 어떻게 심플하게 되어 있는지, 유쾌하게 놀랄 것입니다.
질문에 대한 답변은 프로젝트 요건에 따라 달라집니다.메시지 큐, 컨테이너 관리 글로벌 트랜잭션 등과 같은 Java EE 기능이 필요하지 않은 경우 Tomcat+spring을 사용하십시오.
또한 많은 웹 서비스 통합, 스케줄링, 메시지 큐를 필요로 하는 프로젝트는 Java EE 스택 중 일부를 사용하는 것이 가장 좋다는 것을 경험으로 알게 되었습니다.좋은 점은 스프링을 사용하여 애플리케이션 서버에서 실행되는 Java EE 모듈과 통합할 수 있다는 것입니다.
Java EE 6은 이전 출시와 매우 다르며, 모든 것을 훨씬 더 쉽게 만듭니다.Java EE 6은 다양한 Java 커뮤니티의 최고의 아이디어를 결합합니다. 예를 들어 Spring 프레임워크의 Rod Johnson은 Java EE 6에서 종속성 주입 JSR을 만드는 데 적극적으로 참여했습니다. Java EE 6을 사용하는 이점은 표준에 따라 코딩할 수 있다는 것입니다. 이는 벤더 지원 등에 중요할 수 있습니다.
GlassFish v3는 Java EE 6을 지원하며 매우 가볍고 매우 빠르게 부팅됩니다.글라스피쉬 v3를 개발에 사용하고 있습니다만, 설정이 매우 간단합니다.이 제품에는 서버를 그래픽으로 관리할 수 있는 매우 사용하기 쉬운 관리 콘솔이 포함되어 있습니다.
Glassfish V3 및 JSF 2를 사용하는 경우 Java EE 6의 CDI 기능을 활용하여 JSF에서 대화(예: 페이지)를 쉽게 만들 수 있습니다.
그러나 Java EE 6을 사용하려면 새로운 API를 배워야 합니다.이용 가능한 기간에 따라서는, 최적이 아닌 경우가 있습니다.Tomcat은 오랜 기간 사용되었으며, Tomcat+spring 조합은 많은 웹 프로젝트에서 채택되었습니다. 즉, 많은 문서/포럼이 존재함을 의미합니다.
저는 Spring과 Java EE 6에서 일한 적이 있습니다.제 경험으로 볼 때 오래된 JSP나 독자 사양의 Flex를 선택한다면 Spring과 함께 있으면 안전합니다.
그러나 JSF를 진행하려면 Java EE 6으로 전환해야 합니다.Java EE 6을 사용하면 Facellet 및 표준화된 스크립트 라이브러리 및 구성 요소 라이브러리로 이동할 수 있습니다.스크립트 비호환성 및 컴포넌트 라이브러리 매트릭스가 없어졌습니다.
봄 MVC에 대해서는 프로젝트가 너무 커지지 않는 한 좋습니다.대규모 엔터프라이즈 애플리케이션인 경우 Java EE 6을 사용하십시오.그래야 컴포넌트 라이브러리와 자원 번들을 순서대로 유지할 수 있기 때문입니다.
Java EE 풀 스택이 필요한 경우 GlassFish 3.1을 권장합니다.일부 또는 모든 Java EE 6(JBoss 6, WebLogic 10.3.4)을 구현하는 다른 Java EE 컨테이너에 비해 매우 빠르게 시작되며, 재구축에는 몇 초가 소요되며, 거의 모든 것이 구성에 대한 관례로 수행될 수 있습니다. 매우 편리합니다.
Apache Tomcat 7.x를 원하는 기능으로 커스터마이즈할 수 있는 "Light"를 원합니다.다음 라이브러리에서 많이 사용하였습니다.Weld 1.1.0(CDI) JPA 2.0(Hibernate 3.6.x) - 리소스 로컬 트랜잭션 JSF 2.x(Mojarra) 리치페이스 4.0 BIRT 런타임만
Java EE 6은 지난 10년 동안 Java EE 개발자로 활동해 왔으며(초기 EJB, JSF 및 웹 기술에 시달리고 있음), 매우 쉽고 결합이 잘 되어 있으며 현재 하드웨어가 원활하게 실행되므로 스프링의 동기가 된 독창적인 이유는 더 이상 유효하지 않습니다.
그래도 봄을 더 좋아해요.
그리고 JSF는 그냥 넘어갈게요.내 생각에 그건 쓸모없는 기술인 것 같아.봄 MVC가 더 나은 대안이 될 것이다.Flex도 마찬가지입니다.계약 우선 XML 서비스의 관점에서 생각하면 UI에서 백엔드를 완전히 분리할 수 있습니다.
글라스피쉬 v3와 웰드가 더 성숙해질 때까지 기다릴 수 없다면 Spring + Tomcat을 추천합니다.현재 CDI 지원 어플리케이션에서 Glassfish를 실행할 때 메모리 소비량/CPU 부하에 몇 가지 문제가 있습니다.
다 읽지는 않았지만 이제 Java EE 6과의 전쟁에서 EJB3를 사용할 수 있게 되었기 때문에 Tomcat에서 EJB3를 사용할 수 있을 것 같습니다.
Spring이 있는 Tomcat을 추천한 이유는 다음과 같습니다.
- 봄에는 JSP용 백킹 콩을 만들 수 있습니다.
- 스프링을 사용하여 JPA를 통해 객체를 유지합니다.
헤비웨이트 프로세싱이 필요 없기 때문에 Tomcat을 선택하는 것이 좋습니다.
언급URL : https://stackoverflow.com/questions/2499323/java-ee-6-vs-spring-3-stack
'programing' 카테고리의 다른 글
| 이스케이프된 JSON 문자열을 마킹 해제하는 방법 (0) | 2023.03.06 |
|---|---|
| YAML을 사용한 Spring @PropertySource (0) | 2023.03.06 |
| json 파일을 찾을 수 없는 이유는 무엇입니까? (0) | 2023.03.06 |
| CORS를 통한 Ajax 요청을 사용하는 브라우저의 Set-Cookie (0) | 2023.03.06 |
| React에서 CORS 문제를 해결하는 방법JS (0) | 2023.03.06 |