문제

아파치 위켓( http://wicket.apache.org/ ) 및 Apache 태피스트리( http://wicket.apache.org/ ) 이다 컴포넌트 지향 웹 프레임워크s - Apache Foundation의 Stripes와 같은 액션 기반 프레임워크와 반대입니다.두 가지 모두 Java의 구성 요소에서 애플리케이션을 구축할 수 있게 해줍니다. 둘 다 나랑 너무 비슷해 보여.

두 프레임워크의 차이점은 무엇인가요?두 가지 모두 경험한 사람이 있나요?구체적으로:

  • 성능은 어떻고, 상태 처리를 얼마나 맞춤화할 수 있는지, 무국적(stateless)으로 사용할 수 있나요??
  • 구성 요소 모델의 차이점은 무엇입니까?
  • 어떤 애플리케이션을 위해 무엇을 선택하시겠습니까?
  • Guice, Spring, JSR 299와 어떻게 통합됩니까?

편집하다:나는 둘 다에 대한 문서를 읽었고 둘 다 사용했습니다.문서를 읽는 것만으로는 질문에 충분히 답할 수 없지만 한동안 문서를 사용해 본 경험을 바탕으로 질문에 답할 수 있습니다.고성능 사이트를 위해 상태 비저장 모드에서 Wicket을 사용하는 방법.감사해요.

도움이 되었습니까?

해결책

내가 볼 수있는 몇 가지 관련 차이점 :

  • Tapestry는 반 정적 페이지 구조를 사용하여 조건부 및 루프로 작업하여 동적 동작을 달성 할 수 있습니다. 개찰구는 완전히 역동적입니다. 구성 요소를 동적으로로드하고 런타임에 교체 할 수 있습니다. 그 결과는 태피스트리를 최적화하기 쉽고 개찰구가 사용이 더 유연하다는 것입니다.
  • 두 프레임 워크는 모두 실행이 거의 똑같이 효율적이지만 개찰구는 서버 측 스토리지에 의존합니다 (세션의 현재 페이지와 과거 페이지는 파일 시스템의 기본값 인 '2 단계 캐시'의 과거 페이지). 그것이 당신을 귀찮게한다면, 당신이 피크 타임에 가질 것으로 예상되는 동시 세션 수에 대해 생각하고 세션 당 ~ 100kb로 계산하십시오 (아마도 높음). 즉, 2GB의 20K 동시 세션을 대략적으로 지원할 수 있습니다. 다른 것들에 대해서도 그 기억이 필요하기 때문에 15k라고 말하십시오. 물론, 상태 저장의 단점은 세션 친화력과 잘 작동한다는 것입니다. 따라서 개찰구를 사용할 때 제한이 있습니다. 이 프레임 워크는 무국적 페이지를 구현할 수있는 수단을 제공하지만 완전히 무국적 애플리케이션을 개발하는 경우 다른 프레임 워크를 고려할 수 있습니다.
  • 개찰구의 목표는 정적 타이핑을 최대한 지원하는 반면, 태피스트리는 코드 줄을 저장하는 것입니다. 따라서 태피스트리를 사용하면 코드베이스가 더 작아 유지 보수에 적합하고 개찰구를 사용하면 정적으로 입력되어 IDE로 탐색하고 컴파일러로 쉽게 확인할 수 있으며 유지 보수에도 적합합니다. 두 IMHO 모두에게 할 말이 있습니다.

나는 사람들이 개찰구가 상속을 통해 많은 일을한다고 생각하기 때문에 지금까지 몇 번 읽었습니다. 나는 당신이 선택의 여지가 있다고 강조하고 싶습니다. 구성 요소의 계층 구조가 있지만 개찰구는 iBehavior와 같은 구성을 통해 구성을 지원합니다 (예 : 개찰구의 AJAX 지원이 구축됨). 또한 컨버터 및 유효성 검사기와 같은 것들이 있으며, 이는 일부 위상 리스너가 제공하는 일부 위상 리스너를 사용하여 구성 요소, 또는 심지어는 크로스 커팅 문제로 추가됩니다.

다른 팁

개정됨 태피스트리 5를 공부한 후.

위켓의 목표 만들기 위한 시도이다 데스크탑 GUI와 유사한 웹 개발 하나.그들은 메모리 사용량(HTTPSession)을 희생하면서 정말 잘 해냈습니다.

태피스트리 5의 목표 만드는 것이다 매우 최적화됨(CPU ​​및 메모리에 대해) 컴포넌트 지향 웹 프레임워크.

나에겐 정말 큰 함정 "개찰구가 무국적 구성 요소를 지원합니다!" "개찰구는 기억이 배고프다"는 주장에.Wicket은 실제로 상태 비저장 구성 요소를 지원하지만 "Wicket 개발의 초점"은 아닙니다.예를 들어 StatelessForm의 버그는 오랫동안 수정되지 않았습니다. StatelessForm - 검증 실패 후 매개변수 문제.

  • Wicket을 사용하는 IMHO는 웹 애플리케이션 매개변수를 최적화/미세 조정하기 전까지는 조금 더 쉽습니다.
  • IMHO Wicket은 웹 애플리케이션을 프로그래밍했고 요청 처리 측면에서 생각하고 싶다면 연구하기가 더 어렵습니다.
  • 태피스트리 5 자동 구성 요소 클래스를 다시 로드합니다. 변경하자마자.두 프레임워크 모두 구성 요소 마크업을 다시 로드합니다.
  • 개찰군 마크업/코드 분리, Tapestry 5는 이러한 능력을 제공합니다.Tapestry 5에서는 덜 장황한 구문을 사용할 수도 있습니다.언제나 그렇듯이 이 자유에는 더 많은 주의가 필요합니다.
  • Wicket의 핵심은 디버그하기가 더 쉽습니다.사용자 구성 요소는 상속을 기반으로 하는 반면 Tapestry 5 사용자 구성 요소는 주석을 기반으로 합니다.다른 측면에서는 Wicket보다 Tapestry에서 향후 버전으로 더 쉽게 전환할 수 있습니다.

안타깝게도 태피스트리 5 튜토리얼 't:loop source="1..10"...'과 같은 태피스트리 코드 예제가 나쁜 습관이 될 수 있다는 점을 강조하지 않습니다.따라서 팀 규모가 그리 작지 않다면 태피스트리 사용 규칙/우수 사례를 작성하는 데 약간의 노력을 기울여야 합니다.

내 추천:

  • 페이지 구조가 매우 동적이고 사용자당 10-200Kbs의 HttpSession 메모리를 소비할 여유가 있는 경우 Wicket을 사용하세요(대략적인 수치입니다).
  • 보다 효율적인 리소스 사용이 필요한 경우 Tapestry 5를 사용하십시오.

IBM의 개발자 작품과의 철저한 비교가 있습니다.

http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=Drs

업데이트 : 링크는 죽었지 만 페이지를 찾을 수 있습니다. http://web.archive.org/web/201310111174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=Drs

개찰구는 사용하기에 더 간단한 프레임 워크라고 생각합니다.

또한 개찰구는 IDE의 핫 코드 교체 시스템을 통해 클래스 재 장전을 허용합니다. 개찰구가 현재 실행중인 애플리케이션 클래스의 수정 된 버전을 실행하는 데 필요한 모든 것입니다. 일반적인 제한 사항은 디버그 모드 (ECLIPSE)에서 실행해야하고 클래스의 구조적 측면 (즉, 클래스 이름, 변경 메소드 서명 등)을 변경할 수없는 것과 같은 핫 코드 교체에 적용됩니다.

태피스트리 프로그래밍 모델이 마음에 들지 않으며 많은 변화와 비 호환성으로 인해 태피스트리를 떠나는 많은 개발자들이 알고 있습니다. 보다: http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-and-grails/

개찰구는 매우 좋은 웹 프레임 워크입니다. 내가 아는 모든 것의 최고. 나는 버전 1.3 이후로 그것을 사용하고 항상 내가 원하는 것을 얻습니다. 개찰구는 스프링과 우수한 통합을 가지고 있습니다. 코드에 @SpringBean 주석을 사용하여 스프링 콩을 수업에 주입하십시오.

노력하다 http://incubator.apache.org/click/ . 놀라운 Java 웹 프레임 워크입니다. 어떤 사람들은 이것을“개찰구 제대로 만들었습니다”라고 부릅니다. ;-)

내가 4.1이 공식 안정적인 릴리스 일 때 말했듯이.

태피스트리의 개발 이력을 잘 살펴보아야합니다. Tapestry는 이전 버전의 지원을 계속하지 않고 많은 비 호환 업그레이드를 수행했습니다. 4.1의 패치는 합리적인 기간 내에 더 이상 처리되지 않습니다. 그것은 내 관점에서 공식 안정 버전에서는 허용되지 않습니다.

태피스트리 5를 사용하겠다고 커밋한다는 것은 다음을 의미합니다.

당신은 커밋자가되어야합니다. 모든 새로운 개발을 따라야하고 가능한 한 빨리 오래된 버전을 포기해야합니다. 안정적인 버전을 직접 유지하십시오.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top