이음새, 개찰구, JSF 또는 GWT를 선택 해야하는 프레임 워크는 무엇입니까? [닫은

Question

나는 Java 프로젝트에서 프레젠테이션 레이어의 기초로 Seam, Wicket, JSF 또는 GWT를 사용할 것인지에 대해 토론하고 있습니다.

구직 시장 고려 사항, 기술의 새로운 기능 및 다른 사용자의 권장 사항을 기반으로 Java Web Frameworks의 선택을이 서브 세트로 좁혔습니다.

이것들을 결정할 때 어떤 요소를 고려해야합니까?

Answer 1

내가 사용한 유일한 것은 JSF이므로 다른 사람들에 대한 피드백을 줄 수는 없지만 JSF에 대한 제가 있습니다. 내 경험에 따르면, 우리가 JSP에서 JSP에서 JSF로 변환 한 순간, 인생은 훨씬 쉬워 졌으므로 얼굴에 집중할 것입니다. 또한 Seam과 JSF가 상호 배타적이지 않은 것처럼 보입니다.

장점 :

• FACELETS XHTML 구성 요소 작성은 간단하여 재사용을 촉진합니다.
• UI : Insert, UI : include 및 UI : UI와 같은 내장 태그를 사용한 괜찮은 템플릿 기능
• Faces-Config를 통해 봄 콩에 간단한 접근
• XHTML 기반 웹 개발자는 Java에 익숙하지 않을 수 있습니다.
• Tomahawk/Trinidad에서 사용할 수있는 좋은 위젯 라이브러리

단점 :

• 게시 요청 만 게시합니다. 이로 인해 북마크가 어려워 질 수 있습니다.
• GWT만큼 내장 된 ajax-y가 아니지만 이음새와 함께 사용하면 고정 될 수 있습니다.

나는 결코 JSF/페이스 성 전문가가 아니므로 내가 놓친 다른 사람들이 있다고 확신합니다. 바라건대 다른 사람도 정교해질 것입니다.

JSF 2.0에 대한 업데이트 :

• 복합 구성 요소로 기능을 더 잘 재사용합니다
• 2.0의 위젯 라이브러리에는 프라임 페이스 및 모자라 스케일이 포함됩니다
• GET 요청 및 북마크를 허용합니다
• Ajax 지원을 구축했습니다
• 보다 http://andyschwartz.wordpress.com/2009/31/whats-new-in-jsf-2/ JSF 2에 대한 자세한 내용

Answer 2

2.0 사양이 나온 이후 버전 1.4와 JSF 이후 GWT를 사용했습니다.

GWT는 클라이언트 측 프레임 워크이며 Java에서 JavaScript를 생성합니다. 당신의 아키텍처는 순수한 클라이언트-서버 일 것입니다. 즉, 다음을 의미합니다.

• 거친 입자 서비스를 사용하는 것이 가장 좋습니다
• 클라이언트쪽으로 이동하는 모든 개체는 완전히 직렬화 할 수 있어야합니다 (게으른 부하 또는 OpenSessionInview 패턴이 없음을 의미합니다)
• GWT 2.0이므로 XHTML을 사용하여 GUI를 설계 할 수 있습니다. 이는 HTML 스타일링 및 구조화와 관련하여 훨씬 쉽습니다.
• GWT는 좋은 아키텍처를 선호하는 경향이 있습니다. 나쁜 리팩터에게
• 완벽한 히스토리 (브라우저 백 버튼, 북마크 가능 URL) 지원은 딱딱한, 당신은 아마도 자신의 것을 굴려야 할 것입니다.

JSF는 구성 요소 기반 프레임 워크이며,보기 우선 디자인 (원하는 경우 코드 베어드)을 갖춘 프레임 워크입니다.

• 일부 유형의 WebApps를 수행하는 것이 더 쉽습니다 (쇼핑 카트와 같은 상태).
• JSF+Seam은 대화를위한 수포가 있습니다 (여러 페이지에서 상태를 유지하는 마법사와 같은 페이지를 생각하십시오)
• 너 ~할 수 있다 스택에 따라 OpenSessionInview를 구현하십시오. 서비스/비즈니스 계층에 EJB를 사용하는 경우 권장되지 않을 것입니다.
• JSF2가 있습니다 훌륭한 Ajax 지원 및 Richfaces와 같은 구성 요소 제품군을 사용하여 멋진 WebApps를 구축 할 수 있습니다.
  • 그러나 절묘한 JavaScript 동작을 원한다면 JavaScript를 작성해야합니다.
• JSF는 클라이언트 또는 서버 측에서 현재 UI 상태를 추적합니다. 이것은 네트워크 트래픽 또는 서버 메모리 간의 트레이드 오프입니다.

이력서:

• GWT 웹에 더 적합합니다 응용 프로그램 최고의 클라이언트 측 성능이 필요한 (Gmail을 생각하십시오). 사용자 정의 구성 요소 (Java를 쓰기)를 쉽게 작성할 수 있으며 서버 측은 서비스 계층 일뿐 아니라 서버 측에서 완전히 상태를 유지할 수 있습니다.
• JSF 구성 요소 중심 물건에 더 적합한 대부분의 CRUD 애플리케이션에 더 적합합니다. 호텔/비행 예약 시스템, 쇼핑 카트가있는 온라인 상점 등을 생각하십시오.

Answer 3

냉정 하고이 토론을 계속 해준 개찰 녀석에게 감사드립니다. 나는 개찰구 사용자이고 나는 그것을 좋아합니다. 나의 주요 이유는 다음과 같습니다.

1. 구성 요소 프레임 워크입니다. 전체 페이지가 아닌 구성 요소로 작업하는 것을 좋아합니다.

2. Java 부품에서 작업 할 때 디자이너가 템플릿과 페이지에서 작업하도록 할 수 있습니다.

3. 배울 새로운 것은 없습니다. 그것의 "Just Java와 그냥 html"

4. 나는 Ajax 폴백 메커니즘을 좋아합니다. 특히 모바일 장치에서 브라우저에서 JavaScript 지원이없는 경우 일반 HTML로 돌아가 모든 것이 작동합니다.
5. XML 구성 부족은 플러스입니다
6. 웹 응용 프로그램에서 원하는 모든 것을 지원합니다. 예를 들어 유효성 검사, 국제화, 뒤로 버튼 지원 및 편안한 URL

이전 경험은 GWT 및 JSF 1.0입니다

Answer 4

Seam은 실제로 프레젠테이션 계층이 아닌 애플리케이션 프레임 워크입니다. 원래 JSF를 덜 고통스럽게 만들기 위해 개발되었지만보다 일반적인 의존성 주입 프레임 워크로 발전했습니다.

JSF, 개찰구 및 GWT와 함께 이음새를 사용할 수 있다고 생각합니다. JSF 지원은 주요하고 우수합니다. 다른 두 사람이 얼마나 잘 지원되는지 잘 모르겠습니다.

기준의 초점은 기술의 시장성 인 것처럼 보이므로 얼굴을 통해 이음새와 JSF를 시험해 보는 것이 좋습니다. JSF는 잘 받아 들여지는 표준이며 실제로 페이스 섹션을 사용하는 경우 사용하기에 즐겁습니다. Richfaces와 Ajax4JSF를 통해 매끄러운 Ajax 기능을 가질 수 있습니다. 이음새는 JCP를 통해 다소 표준화되고 있습니다.

Answer 5

내 경험은 연대순으로 다음과 같습니다.

Raw Servlets- (예, 많은 노력을 기울이지 만 초기에는 우리가 열심 인 비버였습니다!)

JSP- 나는 그것이 나올 당시 Beez Neez라고 생각했다 (우리가 알고 있다면;)))

Echo- 멋진 프레임 워크이지만 검색 엔진 친화적 인 페이지 (GWT와 동일한 문제)

개찰구 - 멋진 프레임 워크 - 개발자는 OO의 개념을 완전히 이해하고 (JSP 및 기타 여러와는 달리) 모든 일반적인 OO 니스를이 프레임 워크에 적용했습니다. '재사용 성'에 감사한다면, 캡슐화에 감사한다면, 우려의 분리에 감사하고 물체 마샬링 및 다른 추악함에 대해 걱정할 필요없이 모델을 UI 코드에 바인딩하고 싶다면 이것이 당신을위한 프레임 워크입니다!

Answer 6

장기 시나리오에서는 태양 사양으로 뒷받침되는 기술을 사용하는 것이 좋습니다. 이는 지금까지 여러 구현을 제공하여 선택 (종종 오픈 소스 구현)을 제공하는 것으로 입증되었으며, 행동은 매우 잘 정의되는 경향이 있습니다.

이는 관리 시나리오에서 도움이 될 것입니다. 잘 쓰여진 코드는 영원히 산다 :)

이 특정 시나리오에서는 JSF를 제안합니다. Apache 구현 1.1 만 시도했지만 JSP 위에있는 것은 아프다. 우리는 곧 그것을 수정해야합니다 - 나는 얼굴에 JSF를 가지고있을 것으로 기대합니다.

Answer 7

나는 개찰구와 GWT를 꽤 많이 사용했습니다. 개찰구를 사랑하는 법을 배운 적이 없습니다.

내 자아가 그것에 대해 블로그를 작성했습니다 http://salk31.blogspot.com/2009/07/wicket-ajax.html

오늘 GWT 2.0 Uibinder를 살펴보면 XML 구성 요소 트리를 Java로 만든 것과 일치시키는 것이 개찰에서 얼마나 성가신 지 상기시켜주었습니다. 이것에 대한 GWT 스핀은 나에게 훨씬 더 좋아 보인다.

나는 1 년 넘게 개찰구를 사용하지 않았으므로 아마도 이것을 많이 수정했을 수도 있지만 최신 브라우저와 JS 지원을 감안할 때 서버 에서이 모든 작업을 수행하는 시점을 볼 수 없습니다 (데이터 로컬을 알고 있습니다).

Answer 8

구직 시장 만 고려하면 JSF를 선택해야합니다. 그러나 나는 RIA의 미래가 GWT와 GWT와 같은 클라이언트 측 기술에 속한다고 믿는다.

GWT의 가장 명백한 상승은 JSF, 개찰구와 같은 서버 측 프리젠 테이션 레이어 기술보다 더 잘 확장 가능하다고 생각합니다. 서버는 클라이언트 상태를 저장할 필요가없고 클라이언트 CPU 전원도 사용되기 때문에 큰 이점이므로 결함 허용 시스템을 달성하기 위해 서버 컴퓨터간에 클라이언트 상태를 직렬화 할 필요가 없습니다.

Answer 9

나는 그것이 조금 늦었다는 것을 알고 있지만 Framewrok에 대해 이미 많은 비교가 있습니다.

http://www.devoxx.com/display/devoxx2k10/comparing+jvm+web+frameworks

이것은 당신이 선택하는 데 도움이 될 것입니다 :)

Answer 10

나는 JSF (1.1과 1.2)로 시작했고 다음 프로젝트에서 변화하기로 결정한 것은 너무 고통 스러웠습니다. 나는 조금 조사했고 개찰구를 시도하기로 결정했고, 그것은 매우 즐거웠습니다. 또한 JSF 2를 시도했지만 여전히 같은 것입니다.

둘 다 구성 요소 프레임 워크이지만 개찰구가있는 것들은 쉽지만 JSF를 사용하는 것은 완전한 혼란입니다.

JSF의 개찰구 :

• 개찰에서 HTML은 HTML입니다. JSF에는 자체 마크 업 태그가 있습니다. H : 데이터 가능 (테이블 용)은 말도 안됩니다. 날 믿어, Sun Engineers는 설계했을 때 취해야했습니다.
• 보안과 같은 개찰부에서
• JSF를 사용하면 내비게이션 바에 이전 URL이 표시됩니다. 정말 이상합니다.
• JSF는 나에게 매우 무겁고 라이브러리가 Rich 또는 Prime과 같은 것 같습니다.
• 때로는 어떤 일이 일어나고 있는지 아는 것이 불가능한 것 같습니다. JSF가 왜하고 있는지 모르기 때문에 항상 컴퓨터에서 소리를 지르며 결국 결국 컴퓨터에서 소리칩니다.

개찰구 위의 JSF :

• 개찰구에서는 더 많은 Java (HTML을 사용한 바인딩)를 쓸 것입니다. 적어도 귀하의 IDE는 리팩토링 및 검증 지원을 제공합니다.
• 개찰구의 리소스 관리는 약간 까다 롭습니다.
• JSF에 대한 더 많은 문서와 지원이 있습니다

일반적인 결함 중 하나는 세션 크기가 문제라는 것입니다 (그래픽 구성 요소가 저장되어 있기 때문에).

대체로 개찰구와 JSF 사이에만 결정해야한다면 의심의 여지가 없습니다. 창구.

Answer 11

JSF는 더 이상 사용되지 않습니다 (JSF는 2010 년 전도사가 웹 프레임 워크를 비교하거나 이야기 할 때 비교할 때의 프레임 워크로 나열되지 않습니다).

이제 GWT, YUI, JQuery 등을 사용하여 전체 플러그 대규모 응용 프로그램이 작성됩니다.

Google의 일부 기사를 읽으십시오. 위는 분명합니다.

(JSF의 모든 작업은 레거시 응용 프로그램을 지원하는 것입니다).