여러 Java 웹 프레임 워크의 장단점은 무엇입니까?

여러 Java 웹 프레임 워크의 장단점은 무엇입니까? [닫은]

---

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)는 새로운 템플릿 구문 (Facelet과 유사)과 단순화 된 구성 요소 모델 (단지 1 개의 파일에있는 사용자 정의 구성 요소 ... 마지막으로)을 사용하여 실제로 자체적으로 가져올 것이라고 생각합니다.

그리고 물론 자체적으로 팔로우하는 작은 프레임 워크와 도구가 백만 개 있습니다 ( 기본 요구 사항에 대한 Velocity , 원시 JSP , Struts 등). 하지만 저는 일반적으로 컴포넌트 지향 프레임 워크를 선호합니다.

결국 Tapestry, Wicket 및 JSF를 살펴보고 가장 기분이 좋은 것을 선택하는 것이 좋습니다. 매우 빠르게 일하는 방식에 딱 맞는 것을 찾을 수있을 것입니다.

---

제가 가장 좋아하는 것은 Spring Framework입니다. 2.5 Spring MVC는 새로운 어노테이션, 구성 기능에 대한 관례 등을 포함하여 너무나 굉장합니다.

매우 간단한 작업을 수행하는 경우 프레임 워크를 사용하지 않고 일반 Servlet API를 사용해 볼 수도 있습니다.

---

컴포넌트 지향 Wicket 프레임 워크를 권장합니다 . 이를 통해 웹 애플리케이션을 일반 Java 코드로 작성할 수 있으며 POJO를 모든 구성 요소의 모델로 사용할 수 있으며 거대한 XML 구성 파일을 엉망으로 만들 필요가 없습니다.

Wicket을 발견했을 때 Struts로 온라인 뱅킹 애플리케이션을 성공적으로 개발했고 웹 애플리케이션 개발이 얼마나 쉬운 지 보았습니다!

---

최근에 Stripes Framework를 사용하기 시작했습니다 . 정말 사용하기 쉬운 요청 기반 프레임 워크를 찾고 있지만 수행중인 작업에 제한을 두지 않는 경우이를 적극 권장합니다.

스트럿과 비슷하지만 그 이상입니다. 매우 적은 구성으로 최대 절전 모드 또는 jpa를 사용할 수있는 플러그인 프로젝트도 있습니다.

개찰구도 좋은 것이라고 들었지만 좋은 프레임 워크가 많이 있지만 사용하지 않았습니다.

---

직접 시도 해본 적은 없지만

http://www.playframework.org/

많은 잠재력이 있습니다 ...

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로 고통스러운 전환을 한 후 나는 거의 즉시 버려 졌다고 느꼈습니다.

Of course, with the release of Tapestry 5, Tapestry 4 became a legacy product. I wouldn't have a problem with this if the upgrade path wasn't so brutal again. So now our development team is in the rather unenviable position: We could continue to use an essentially abandoned web platform (Tapestry 4), make the heinous upgrade to Tapestry 5, or give up on Tapestry entirely and rewrite our application using another platform. None of these options is very attractive.

Tapestry 5 is supposedly written so as to reduce the likelihood of update breakage from this point forward. A good example is in the page classes: in previous incarnations, page classes descended from a base class provided by Tapestry; incompatible API changes in this class were the cause of a large number of backward compatibility problems. In Tapestry 5, pages are POJOs which are enhanced at runtime with the "magic Tapestry fairy dust" via annotations. So as long as the contract for the annotations is maintained, changes to Tapestry won't affect your page classes.

If this is right, then writing a new application using Tapestry 5 could turn out well. But personally, I don't feel like putting my hand on the burner again.

---

Disclamer: I work at Vaadin (previously IT Mill)

If you are doing something RIAish, you might want to take look at Vaadin. It's an open source UI-oriented AJAX framework that, to me, is nice to use (I come from a PHP background myself).

There's a case study that compares doing the same application (i.e. two applications with the same set of features) in Icefaces and Vaadin. In a nutshell, it states that the UI development was considerably faster.

Even though the study is hosted at the company's wiki, I can assure that it's objective, genuine and truthful, although I can't force you in believing me.

---

After a long while of testing various solutions, for me it turned out to be:

• Spring MVC for the presentation and controller layer (NO Spring Webflow though, because my flows are based on ajax)

• jQuery for all the client side stuff

• Spring Security for the, well, security aspect

• Hibernate / JPA2

• Jetty for the sake of continuations (comet)

One month of an extraordinarily steep learning curve, but now I am happy.

I would also like to mention that I was just a little step away from skipping all that Java stuff and learing Scala/LIFT instead. As far as I am concerned, everything in Java that is related with cutting edge web development (comet, async communication, security (yes, even with Spring Security!)) still is a bit of a hack (proove me wrong by evidence, pleeease!). To me, Scala/LIFT seems to be a more out-of-the-box and all-in-one solution.

The reason why I finally decided not to go with Scala is

• as a project leader I must consider human resources and Java developers are much easier to find than Scala developers

• for most developers in my team, Scala's funcional concept, as excellent as it is, is hard to understand

Cheers Er

---

I've heard good things about the Spring Framework too. In general, though, I've been underwhelmed by most Java web frameworks I've looked at (esp Struts).

For a simple app I'd definitely consider using "raw" servlets and JSPs and not worry about adopting a framework. If the servlets are well written, it should be straightforward in the future to port to a framework if necessary when the app grows in complexity.

---

My pick is Wicket!!

---

All of them - that's the problem ;-)

---

I think for your modest requirements, you just need to code up servlets or simple jsp pages that you can serve from Tomcat server. I dont think you need any kind of web-framework (like struts) for personal web-site data

---

Saying "use JSF" is a little to simple. When you decide to use JSF, you have to choose a component library on top of it. Will you use MyFaces Tomahawk, Trinidad, Tobago (http://myfaces.apache.org/)? Or maybe ICEfaces (http://www.icefaces.org/)? Oh, and if you use ICEfaces, will you use JSPs or Facelets for your views?

In my opinion it is to hard to tell. Nobody has the time to evaluate all the promising alternatives, at least in the projects I work on, because they are not big enough to do three month evaluation phases. However, you should look around for some that has a big and active community and isn't gone in a year. JSF is around for some time, and since it gets pushed by sun, it will be around for some more. I can't say if it's the best choice, but it will be a good one.

---

http://zkoss.org - the good one

---

For high traffic sites I'd use a framework that doesn't manage client state on the server - Wicket, JSF and Tapestry are managing client state on the server. I'd only use those frameworks (Wicket is my favourite) if the application should be more like a desktop application. But I'd try to use a more scalable and simple REST+AJAX approach though.

Spring MVC would be a candidate, but since Spring MVC 3 it has a strange annotation overloaded programming model which doesn't use the benefits of static typing. There ore other ugly things like output parameters in methods combined with a usual return, so there are two output channels of one method. Spring MVC also tends to reeinvent the wheel and you'll have more to configure compared to other frameworks. I cannot really recommend Spring MVC though it has some nice ideas.

Grails is a convenient way to use Spring MVC and other established frameworks like Hibernate. Coding is fun and you'll quickly see results.

And don't forget that the Servlet API with a few little helpers like FreeMarker for templating is very powerful.

---

I have evaluated quite a few frameworks and Vaadin (http://vaadin.com/home) has percolated all the way to the top.

You should at least give it a short evaluation.

Cheers!

---

My pick would be Wicket (for large projects and a predictable user base), GWT (for large projects that are mostly public facing) or just a service framework (like Jersey/ JAXRS) together with a JavaScript toolkit (for small to medium projects).

---

I recommend Seam, especially if you need persistence.

---

See a few comments on some Java application Frameworks (second paragraph):

http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html

---

For quick and fancy GUI you can use JSF with Richfaces library. Richfaces UI components are easy to use and handy references available with code demonstration in the demo site. Probably later when your site has more data to handle and lot of information has to be transacted in database you can plug any database access framework (ORM) with it.

---

Can't believe no one has mentioned GWT

---

My favorite way to go for really simple apps is Apache VelocityTools (VelocityLayoutServlet) with Velosurf (http://velosurf.sourceforge.net).

For more complex apps, Spring MVC or Struts 2.

---

Try HybridJava - that is much simpler than anything else.

---

I would say vaadin or wicket

참고URL : https://stackoverflow.com/questions/24596/what-are-the-pros-and-cons-of-the-assorted-java-web-frameworks