Java를 사용하여 웹 사이트를 만드는 것을 고려하고 있으며 사용할 프레임 워크를 결정하려고합니다. 그러나 Java 프레임 워크를 빠르게 검색하면 선택할 수있는 항목이 50 개 이상 반환됩니다!
내 웹 사이트는 처음에 그것을 구축하는 나의 즐거움을위한 것일 뿐이지 만, 그것이 인기를 얻게된다면, 어느 정도의 확장 성을 가지거나 적어도 그것을 위해 재 설계 할 수 있으면 좋을 것입니다.
더 많이 사용되는 프레임 워크의 주요 차이점은 무엇입니까? 하나가 다른 것보다 훨씬 뛰어난 경우가 있습니까? 예를 들어 트래픽이 많은 엔터프라이즈 애플리케이션과 트래픽이 적은 소규모 애플리케이션이 있습니다. 또한 일부가 다른 것보다 배우고 사용하기가 훨씬 쉬운 지 궁금합니다.
이러한 프레임 워크에 대한 경험이 있고 추천 할 수있는 사람이 있습니까? 엄청나게 많은 선택이 가능한 경우 Java 기반 웹 개발을 피하기위한 조기 경고 역할을합니까?
답변:
나는 Tapestry 3 , Wicket , Echo 및 JSF를 상당히 광범위하게 사용했습니다. 나는 당신이 그것들을 살펴보고 당신에게 가장 쉬운 것처럼 보이는 것을 선택하고 당신이 일하는 방식에 가장 잘 맞는 것을 정말로 추천합니다.
그들 중 제가 작업하기에 가장 편한 것은 Wicket 이었습니다. 구성 요소 빌드의 경량 특성과 페이지 템플릿의 단순성 때문입니다. Hibernate 또는 다른 프레임 워크 대신 자신의 db 코드를 사용하는 경우 두 배로 진행됩니다 (나는 Wicket Hibernate 또는 Spring Integration에 완전히 만족하지 않았습니다).
Echo 는 모든 레이아웃을 Java로 작성하는 데 신경 쓰지 않는다면 훌륭합니다. 지금은 다르다는 것을 알고 있지만 여전히 제품이 상당히 좁은 틈새 시장을 제공한다고 생각합니다. 그들은 모든 주요 릴리스에서 개발 모델을 변경합니다.
태피스트리 는 훌륭한 제품이지만, 주로 한 친구가 주도하는 개발 모델 측면에서 다른 제품과 분명히 다릅니다. Howard Lewis Ship은 의심 할 여지없이 매우 똑똑하지만 기본적으로 각 릴리스와의 하위 호환성을 잊어 버리기로 한 그들의 결정에 실망합니다. 다시 말하지만, 귀하의 필요에 따라 이것은 중요하지 않을 수 있으며, 나는 항상 Tapestry 제품이 작업하기에 즐겁다는 것을 발견했습니다.
JSF 는 수년 동안 사용되어 왔지만 여전히 Struts의 모든 문제를 해결하기 위해 구축 한 것처럼 느껴집니다 . Struts의 모든 문제를 실제로 이해하지 못합니다. 제품은 분명히 매우 유연하지만 아직 완성되지 않은 느낌이 있습니다. 나는 그것을 사용하고 그것을 좋아하고 미래에 대한 큰 희망을 가지고 있습니다. JEE6에서 제공 될 다음 릴리스 (2.0)는 새로운 템플릿 구문 (Facelets과 유사)과 단순화 된 구성 요소 모델 (단지 1 개의 파일에있는 사용자 정의 구성 요소 ... 마지막으로)을 사용하여 실제로 자체적으로 가져올 것이라고 생각합니다.
그리고 물론 자체적으로 팔로우하는 작은 프레임 워크와 도구가 수백만 개 있습니다 ( 기본 요구 사항에 대한 Velocity , 원시 JSP , Struts 등). 하지만 저는 일반적으로 컴포넌트 지향 프레임 워크를 선호합니다.
결국 나는 Tapestry, Wicket 및 JSF를 살펴보고 가장 기분이 좋은 것을 선택하는 것이 좋습니다. 매우 빠르게 작업하는 방식에 딱 맞는 것을 찾을 수있을 것입니다.
내가 가장 좋아하는 것은 Spring Framework입니다. 2.5 Spring MVC는 새로운 어노테이션, 구성 기능에 대한 관례 등을 포함하여 너무나 굉장합니다.
매우 간단한 작업을 수행하는 경우 프레임 워크를 사용하지 않고 일반 Servlet API를 사용해 볼 수도 있습니다.
컴포넌트 지향 Wicket 프레임 워크를 권장합니다 . 이를 통해 웹 애플리케이션을 일반 Java 코드로 작성할 수 있으며 POJO를 모든 구성 요소의 모델로 사용할 수 있으며 거대한 XML 구성 파일을 엉망으로 만들 필요가 없습니다.
Wicket을 발견했을 때 Struts로 온라인 뱅킹 애플리케이션을 성공적으로 개발했고 웹 애플리케이션 개발이 얼마나 쉬운 지 보았습니다!
최근에 Stripes Framework를 사용하기 시작했습니다 . 정말 사용하기 쉬운 요청 기반 프레임 워크를 찾고 있지만 수행중인 작업에 제한을 두지 않는 경우이를 적극 권장합니다.
스트럿과 비슷하지만 그 이상입니다. 매우 적은 구성으로 최대 절전 모드 또는 jpa를 사용할 수있는 플러그인 프로젝트도 있습니다.
개찰구도 좋은 것이라고 들었지만 좋은 프레임 워크가 많이 있지만 사용하지 않았습니다.
직접 해본 적은 없지만
많은 잠재력이 있습니다 ...
PHP와 고전적인 ASP에서 온 것은 나에게 유망하게 들리는 최초의 자바 웹 프레임 워크이다 ....
업데이트 : Tapestry 5.2가 나왔으므로 이전에 보였던 것처럼 포기되지 않았습니다. 내 경험은 5가 아닌 Tapestry 4를 사용하므로 마일리지가 다를 수 있습니다. Tapestry에 대한 나의 의견은 수년에 걸쳐 변했습니다. 나는 그것을 반영하기 위해이 게시물을 수정했습니다.
이전처럼 더 이상 Tapestry를 추천 할 수 없습니다. Tapestry 5는 상당히 개선 된 것처럼 보이지만 Tapestry의 주요 문제는 플랫폼 자체가 아닙니다. 그것은 뒤에 사람들과 함께합니다.
역사적으로, Tapestry의 모든 주요 버전 업데이트는 극심한 편견과 함께 하위 호환성을 깨뜨 렸습니다. 이는 상당한 재 작성이 필요한 새로운 코딩 기술 또는 기술의 통합 때문인 것 같습니다.
Howard Lewis Ship (Tapestry의 주요 저자)은 확실히 뛰어난 개발자이지만 Tapestry 프로젝트를 관리하는 데 관심이 있다고 말할 수는 없습니다. Tapestry 5의 개발은 Tapestry 4가 출하 된 직후에 시작되었습니다. 내가 말할 수있는 한, Ship은 그것에 거의 헌신했고, 내가 Ship만큼 능력이 없다고 느끼는 다른 기여자들의 손에 Tapestry 4를 맡겼습니다. 태피스트리 3에서 태피스트리 4로 고통스러운 전환을 한 후 나는 거의 즉시 버려 졌다고 느꼈습니다.
물론 Tapestry 5의 출시와 함께 Tapestry 4는 레거시 제품이되었습니다. 업그레이드 경로가 다시 는 그렇게 잔인하지 않다면 나는 이것에 문제가 없을 것 입니다. 이제 우리 개발 팀은 다소 부러워 할 수없는 위치에 있습니다. 본질적으로 버려진 웹 플랫폼 (Tapestry 4)을 계속 사용하거나 Tapestry 5로 가혹하게 업그레이드하거나 Tapestry를 완전히 포기하고 다른 플랫폼을 사용하여 애플리케이션을 다시 작성할 수 있습니다. 이러한 옵션 중 어느 것도 그다지 매력적이지 않습니다.
Tapestry 5는이 시점부터 업데이트가 중단 될 가능성을 줄이기 위해 작성되었습니다. 페이지 클래스에 좋은 예가 있습니다. 이전 버전에서는 Tapestry에서 제공하는 기본 클래스의 후손 인 페이지 클래스입니다. 이 클래스의 호환되지 않는 API 변경은 많은 이전 버전과의 호환성 문제의 원인이었습니다. Tapestry 5에서 페이지는 주석을 통해 "마법의 태피스트리 요정 먼지"로 런타임에 향상되는 POJO입니다. 따라서 주석에 대한 계약이 유지되는 한 Tapestry에 대한 변경 사항은 페이지 클래스에 영향을주지 않습니다.
이것이 맞다면 Tapestry 5를 사용하여 새 응용 프로그램을 작성하는 것이 좋습니다. 하지만 개인적으로 다시는 버너에 손을 얹고 싶지 않습니다.
Disclamer : 저는 Vaadin (이전 IT Mill)에서 근무합니다.
뭔가 RIAish를하고 있다면 Vaadin 을 살펴보고 싶을 것 입니다. 나에게는 사용하기 좋은 오픈 소스 UI 지향 AJAX 프레임 워크입니다 (저는 PHP 배경에서 왔습니다).
있다 사례 연구 Icefaces 및 Vaadin이 동일한 응용 프로그램 (동일한 기능 세트, 즉 두 개의 응용 프로그램을)하고 비교합니다. 간단히 말해서 UI 개발이 상당히 빨랐습니다.
이 연구가 회사의 위키에서 주최되지만, 객관적이고 진실하며 진실하다는 것을 확신 할 수 있습니다. 비록 당신이 나를 믿도록 강요 할 수는 없지만.
오랜 시간 동안 다양한 솔루션을 테스트 한 결과 다음과 같은 결과가 나왔습니다.
프레젠테이션 및 컨트롤러 계층을위한 Spring MVC (내 흐름은 ajax를 기반으로하기 때문에 Spring Webflow 없음)
모든 클라이언트 측 항목에 대한 jQuery
보안 측면을위한 Spring Security
최대 절전 모드 / JPA2
연속을위한 부두 (혜성)
매우 가파른 학습 곡선의 한 달 이었지만 지금은 행복합니다.
또한 모든 Java 항목을 건너 뛰고 대신 Scala / LIFT를 사용하는 것에서 조금 떨어진 곳에 있음을 언급하고 싶습니다. 내가 아는 한, 최첨단 웹 개발 (혜성, 비동기 통신, 보안 (예, Spring Security에서도 마찬가지 임)) 과 관련된 Java의 모든 것은 여전히 약간의 해킹입니다 (증거로 잘못 입증, 변론 !). 나에게 Scala / LIFT는 좀 더 즉시 사용 가능한 올인원 솔루션 인 것 같습니다.
내가 마침내 Scala를 사용 하지 않기로 결정한 이유 는
프로젝트 리더로서 인적 자원을 고려해야하며 Java 개발자는 Scala 개발자보다 찾기가 훨씬 쉽습니다.
우리 팀의 대부분의 개발자에게 Scala의 기능 개념은 훌륭하지만 이해하기 어렵습니다.
건배 어
그들 모두-그게 문제입니다 ;-)
겸손한 요구 사항에 대해서는 Tomcat 서버에서 제공 할 수있는 서블릿 또는 간단한 jsp 페이지를 코딩하기 만하면됩니다. 개인 웹 사이트 데이터를 위해 어떤 종류의 웹 프레임 워크 (예 : 스트럿)가 필요하다고 생각하지 않습니다.
"JSF 사용"이라고 말하는 것은 약간 간단합니다. JSF를 사용하기로 결정하면 그 위에있는 컴포넌트 라이브러리를 선택해야합니다. MyFaces Tomahawk, Trinidad, Tobago ( http://myfaces.apache.org/ )를 사용 하시겠습니까? 아니면 ICEfaces ( http://www.icefaces.org/ )? 아, 그리고 ICEfaces를 사용하는 경우 뷰에 JSP 또는 Facelet을 사용 하시겠습니까?
제 생각에는 말하기 어렵습니다. 적어도 내가 작업하는 프로젝트에서 모든 유망한 대안을 평가할 시간이 없습니다. 3 개월 평가 단계를 수행 할만큼 충분히 크지 않기 때문입니다. 그러나 크고 활동적인 커뮤니티가 있고 1 년 안에 사라지지 않은 커뮤니티를 찾아보아야합니다. JSF는 한동안 주위에 있고, 태양에 의해 밀려 나기 때문에 더 많이있을 것입니다. 최선의 선택인지는 말할 수 없지만 좋은 선택이 될 것입니다.
http : //zkoss.org- 좋은 것
트래픽이 많은 사이트의 경우 서버에서 클라이언트 상태를 관리하지 않는 프레임 워크를 사용합니다. Wicket, JSF 및 Tapestry는 서버에서 클라이언트 상태를 관리합니다. 응용 프로그램이 데스크톱 응용 프로그램과 더 비슷해야하는 경우에만 해당 프레임 워크 (Wicket이 가장 좋습니다)를 사용합니다. 하지만 더 확장 가능하고 간단한 REST + AJAX 접근 방식을 사용하려고합니다.
Spring MVC가 후보가 될 수 있지만 Spring MVC 3 이후로 정적 타이핑의 이점을 사용하지 않는 이상한 주석 과부하 프로그래밍 모델이 있습니다. 일반적인 리턴과 결합 된 메소드의 출력 매개 변수와 같은 다른 추악한 것들이 있으므로 한 메소드의 두 개의 출력 채널이 있습니다. Spring MVC는 또한 휠을 재발견하는 경향이 있으며 다른 프레임 워크에 비해 구성 할 것이 더 많습니다. 좋은 아이디어가 있지만 Spring MVC를 정말로 추천 할 수는 없습니다.
Grails는 Spring MVC 및 Hibernate와 같은 기존 프레임 워크를 사용하는 편리한 방법입니다. 코딩은 재미 있고 결과를 빠르게 볼 수 있습니다.
그리고 템플릿 용 FreeMarker와 같은 몇 가지 작은 도우미가있는 Servlet API가 매우 강력하다는 것을 잊지 마십시오.
일부 Java 애플리케이션 프레임 워크에 대한 몇 가지 주석을 참조하십시오 (두 번째 단락).
http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html
내용은 신속하고 화려한 GUI 당신과 함께 JSF를 사용할 수 있습니다 Richfaces의 라이브러리입니다. Richfaces UI 구성 요소는 데모 사이트의 코드 데모와 함께 사용하기 쉽고 편리한 참조를 제공합니다. 아마도 나중에 사이트에 처리 할 데이터가 더 많고 데이터베이스에서 많은 정보를 처리해야 할 때 ORM (데이터베이스 액세스 프레임 워크)을 연결할 수 있습니다.
정말 간단한 앱을 선호하는 방법은 Velosurf ( http://velosurf.sourceforge.net ) 와 함께 Apache VelocityTools (VelocityLayoutServlet)입니다 .
더 복잡한 앱의 경우 Spring MVC 또는 Struts 2입니다.