各种 Java Web 框架的优缺点是什么？

What are the pros and cons of the assorted Java web frameworks?

提问by Aaron

I am considering creating my own website using Java and am trying to decide what framework to use. However, doing a quick search for Java frameworks returns more than 50 to choose from!

我正在考虑使用 Java 创建我自己的网站，并试图决定使用什么框架。但是，快速搜索 Java 框架会返回 50 多个可供选择的框架！

My website is just going to be for my own enjoyment of building it in the beginning, but if it becomes popular, it would be good for it to have some scalability, or to at least be able to redesign for that.

我的网站一开始只是为了让我自己享受构建它的乐趣，但是如果它变得流行，那么它具有一定的可扩展性或者至少能够为此重新设计会很好。

What are the main differences between the more popular frameworks? Are there instances where one significantly outperforms the others? For example, high-traffic enterprise applications versus low-traffic small applications. I'm also wondering if some are much easier to learn and use than others.

更流行的框架之间的主要区别是什么？是否存在一个明显优于其他的情况？例如，高流量企业应用程序与低流量小型应用程序。我还想知道有些是否比其他的更容易学习和使用。

Is there anyone who has experience with some of these frameworks and can make a recommendation? Does the sheer number of choices just serve as an early warning to avoid Java-based web development where possible?

有没有人对其中一些框架有经验并可以提出建议？如此多的选择是否只是作为一种预警，可以尽可能避免基于 Java 的 Web 开发？

采纳答案by jsight

I've used Tapestry 3, Wicket, Echo, and JSFfairly extensively. I'd really recommend you look those over and pick the one that appears the easiest for you, and to most closely fit the way you prefer to work.

我已经相当广泛地使用了Tapestry 3、Wicket、Echo和JSF。我真的建议您仔细查看这些内容，然后选择对您来说最简单的方式，并且最适合您喜欢的工作方式。

Of them, the most comfortable for me to work with was Wicket, due to the lightweight nature of component building and simplicity of page templating. That goes doubly so if you are using your own db code instead of Hibernate or some other framework (I was never completely happy with Wicket Hibernate or Spring Integration).

其中，对我来说最舒服的是Wicket，因为组件构建的轻量级特性和页面模板的简单性。如果您使用自己的数据库代码而不是 Hibernate 或其他一些框架（我从来没有对 Wicket Hibernate 或 Spring Integration 感到完全满意），那么情况会加倍。

Echois great if you don't mind writing all of your layout in Java. I know that is different now, but I still think that product serves a fairly narrow niche. They change the development model with every major release as well it seems.

如果您不介意用 Java 编写所有布局，Echo非常棒。我知道现在不同了，但我仍然认为该产品服务于相当狭窄的利基市场。他们似乎也在每个主要版本中改变了开发模型。

Tapestryis a great product, but it is obviously very different from the others in terms of development model as it is led mainly by one dude. Howard Lewis Ship is no doubt quite smart, but I am disappointed with their decision to basically forget backwards compatibility with each release. Again, though, for your needs this may not matter, and I've always found the Tapestry products pleasurable to work against.

Tapestry是一个很棒的产品，但它在开发模式上显然与其他产品有很大不同，因为它主要由一个人领导。Howard Lewis Ship 无疑非常聪明，但我对他们决定基本上忘记每个版本的向后兼容性感到失望。不过，同样，对于您的需求，这可能无关紧要，而且我一直发现 Tapestry 产品使用起来很愉快。

JSFhas been out for years, and still feels like something that a Strutsguy built to fix all of the problems of Struts. Without really understanding all of the problems with Struts. It still has an unfinished feel to it, although the product is obviously very flexible. I use it and have some fondness for it, with great hopes for its future. I think the next release (2.0) to be delivered in JEE6 will really bring it into its own, with a new template syntax (similar to Facelets) and a simplified component model (custom components in only 1 file... finally).

JSF已经出来多年了，但仍然感觉像是Struts人为解决Struts 的所有问题而构建的东西。没有真正了解 Struts 的所有问题。它仍然有一种未完成的感觉，尽管该产品显然非常灵活。我使用它并喜欢它，对它的未来充满希望。我认为将在 JEE6 中交付的下一个版本 (2.0) 将真正将其纳入自己的版本，具有新的模板语法（类似于 Facelets）和简化的组件模型（自定义组件仅包含在 1 个文件中......最终）。

And, of course, there are a million smaller frameworks and tools that get their own following (Velocityfor basic needs, raw JSPs, Struts, etc). I generally prefer component oriented frameworks myself, though.

而且，当然，有一百万个较小的框架和工具得到了自己的支持（满足基本需求的Velocity、原始JSP、Struts 等）。不过，我自己通常更喜欢面向组件的框架。

In the end, I'd recommend just taking a look at Tapestry, Wicket, and JSF and just picking the one that feels the best to you. You'll probably find one that just fits the way you like to work very quickly.

最后，我建议您只看一下 Tapestry、Wicket 和 JSF，然后选择最适合您的那个。您可能会很快找到一款适合您喜欢的工作方式的产品。

回答by bpapa

My favorite is the Spring Framework. With 2.5 Spring MVC is soooo kick ass, with new annotations, convention over configuration features, etc.

我最喜欢的是 Spring 框架。使用 2.5 Spring MVC 太棒了，有了新的注释，配置特性的约定等等。

If you're just doing something super simple you could also just try using the regular Servlet API and not bother with a framework.

如果您只是在做一些非常简单的事情，您也可以尝试使用常规的 Servlet API，而不必为框架而烦恼。

回答by Johannes K. Lehnert

I recommend the component oriented Wicketframework. It allows you to write your web application in plain old Java code, you can use POJOs as the model for all components and don't need to mess around with huge XML configuration files.

我推荐面向组件的Wicket框架。它允许您用普通的旧 Java 代码编写 Web 应用程序，您可以使用 POJO 作为所有组件的模型，而无需处理庞大的 XML 配置文件。

I had successfully developed an online banking application with Struts when I discovered Wicket and saw how easy web application development can be!

当我发现 Wicket 并看到 Web 应用程序开发是多么容易时，我已经成功地使用 Struts 开发了一个在线银行应用程序！

回答by ScArcher2

I've recently started using the Stripes Framework. If you're looking for a request based framework that's really easy to use, but doesn't impose any limits on what you are doing I'd highly recommend it.

我最近开始使用Stripes Framework。如果您正在寻找一个非常易于使用的基于请求的框架，但不会对您正在做的事情施加任何限制，我强烈推荐它。

It's similar to struts, but it goes way beyond it. There are even some plugin projects that enable you to do use hibernate or jpa with very little configuration.

它类似于struts，但远不止于此。甚至还有一些插件项目使您能够以很少的配置使用 hibernate 或 jpa。

There are a lot of good frameworks out there though I've heard wicket is a good one as well, but I haven't used it.

尽管我听说 wicket 也是一个很好的框架，但那里有很多好的框架，但我还没有使用过它。

回答by opensas

Haven't tried it myself, but I think

自己没试过，但我觉得

http://www.playframework.org/

http://www.playframework.org/

has a lot of potential...

有很大的潜力...

coming from php and classic asp, it's the first java web framework that sound promising to me....

来自 php 和经典的 asp，它是第一个对我来说很有希望的 java web 框架......

回答by Robert J. Walker

UPDATE: Tapestry 5.2 is out, so it's not abandoned, as it previously appeared to be. My experience is with Tapestry 4, not 5, so your mileage may vary. My opinion of Tapestry has changed over the years; I have modified this post to reflect it.

更新：Tapestry 5.2 已经发布，所以它并没有像以前那样被放弃。我的经验是使用 Tapestry 4，而不是 5，所以您的里程可能会有所不同。多年来，我对 Tapestry 的看法发生了变化。我已经修改了这篇文章以反映它。

I can no longer recommend Tapestry as I did previously. Tapestry 5 appears to be a significant improvement, but my main issue with Tapestry is not with platform itself; it's with the people behind it.

我不能再像以前那样推荐 Tapestry。Tapestry 5 似乎是一个重大改进，但我对 Tapestry 的主要问题不在于平台本身；它与背后的人在一起。

Historically, every major version update of Tapestry has broken backwards compatibility with extreme prejudice, far more than one might expect. This seems to be due to the incorporation of new coding techniques or technologies that require significant rewrites.

从历史上看，Tapestry 的每一次主要版本更新都打破了对极端偏见的向后兼​​容性，远远超出人们的预期。这似乎是由于采用了新的编码技术或需要大量重写的技术。

Howard Lewis Ship (the principal author of Tapestry) is certainly a brilliant developer, but I can't say I care for his management of the Tapestry project. Development of Tapestry 5 began almost immediately after Tapestry 4 shipped. From what I can tell, Ship pretty much devoted himself to that, leaving Tapestry 4 in the hands of other contributors, who I feel are not nearly as capable as Ship. After having made the painful switch from Tapestry 3 to Tapestry 4, I felt that I had been abandoned almost immediately.

Howard Lewis Ship（Tapestry 的主要作者）当然是一位出色的开发人员，但我不能说我关心他对 Tapestry 项目的管理。Tapestry 5 的开发几乎在 Tapestry 4 发布后立即开始。据我所知，Ship 非常投入，将 Tapestry 4 留给了其他贡献者，我觉得他们的能力不如 Ship。在经历了从 Tapestry 3 到 Tapestry 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 的发布，Tapestry 4 成为了一个遗留产品。如果升级路径不再那么残酷，我就不会遇到这个问题。所以现在我们的开发团队处于相当令人羡慕的境地：我们可以继续使用一个基本上被废弃的 Web 平台（Tapestry 4），进行令人发指的升级到 Tapestry 5，或者完全放弃 Tapestry 并使用另一个平台重写我们的应用程序。这些选项都不是很有吸引力。

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.

Tapestry 5 被认为是为了减少从现在开始更新中断的可能性。一个很好的例子是页面类：在以前的化身中，页面类是从 Tapestry 提供的基类派生出来的；此类中不兼容的 API 更改是导致大量向后兼容性问题的原因。在 Tapestry 5 中，页面是 POJO，它们在运行时通过注释使用“神奇的 Tapestry 仙尘”进行了增强。因此，只要维护注释的约定，对 Tapestry 的更改就不会影响您的页面类。

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.

如果这是正确的，那么使用 Tapestry 5 编写一个新的应用程序可能会很好。但就个人而言，我不想再次把手放在燃烧器上。

回答by Henrik Paul

Disclamer: I work at Vaadin (previously IT Mill)

免责声明：我在 Vaadin（以前是 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).

如果你正在做一些 RIAish，你可能想看看Vaadin。这是一个开源的面向 UI 的 AJAX 框架，对我来说，它很好用（我自己来自 PHP 背景）。

There's a case studythat 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.

有一个案例研究比较了在 Icefaces 和 Vaadin 中执行相同的应用程序（即具有相同功能集的两个应用程序）。简而言之，它指出 UI 开发速度要快得多。

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.

尽管该研究是在公司的 wiki 上进行的，但我可以保证它是客观、真实和真实的，尽管我不能强迫您相信我。

回答by Ta Sas

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)

• 表示层和控制器层的 Spring MVC（虽然没有 Spring Webflow，因为我的流基于 ajax）

• jQuery 用于所有客户端的东西

• 用于安全方面的 Spring Security

• 休眠/JPA2

• 为了延续的码头（彗星）

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.

我还想提一下，我离跳过所有 Java 内容并学习 Scala/LIFT 仅一步之遥。就我而言，Java 中与尖端 Web 开发相关的所有内容（彗星、异步通信、安全性（是的，即使使用 Spring Security！））仍然有点黑客（请用证据证明我错了，请！）。对我来说，Scala/LIFT 似乎是一种更开箱即用的一体化解决方案。

The reason why I finally decided notto go with Scala is

我最终决定不使用 Scala 的原因是

• 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

• 作为项目负责人，我必须考虑人力资源和 Java 开发人员比 Scala 开发人员更容易找到

• 对于我团队中的大多数开发人员来说，Scala 的功能概念虽然非常出色，但很难理解

Cheers Er

干杯儿

回答by Russell Mayor

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).

我也听说过有关 Spring 框架的好消息。不过，总的来说，我对我看过的大多数 Java Web 框架（尤其是 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.

对于一个简单的应用程序，我肯定会考虑使用“原始”servlet 和 JSP，而不用担心采用框架。如果 servlet 编写得很好，那么将来当应用程序变得复杂时，如有必要，移植到框架应该很简单。

回答by Franklin

My pick is Wicket!!

我的选择是检票口！！