我正在考虑在Java项目的表现层中使用Seam、Wicket、JSF或GWT作为基础。
基于就业市场的考虑、技术的新颖性以及其他S.O.用户的推荐，我将我的Java Web框架选择缩小到了这个子集。
在这些框架中做决策时应该考虑哪些因素？
11个回答
34
我从1.4版本开始使用GWT，从2.0版本规范推出后开始使用JSF。
GWT是一个客户端框架，它可以从Java生成JavaScript。你的架构应该是一个纯客户端-服务器模式，这意味着：
- 最好使用粗粒度服务
- 所有到客户端的对象都应该是完全可序列化的（这意味着没有惰性加载或OpenSessionInView模式）
- 自GWT 2.0以来，您可以使用xhtml设计您的GUI，这在样式和HTML结构方面要容易得多
- GWT倾向于良好的架构，如果你搞砸了，重构起来会很麻烦
- 完美的历史记录（浏览器后退按钮，可书签的URL）支持很难实现，您可能需要自己编写，尽管在一开始很容易黑进去一些东西
JSF是一个基于组件的框架，具有视图优先的设计（如果您喜欢，也可以使用代码后台）：
- 某些类型的web应用程序（有状态的，如购物车）更容易实现
- JSF+Seam支持对话（类似向导页面，可以在几个页面之间保持状态）
- 您可以实现OpenSessionInView，具体取决于您的堆栈。如果您在服务/业务层使用EJB，则可能不建议这样操作
- JSF2对AJAX提供了极好的支持，如果使用RichFaces等组件套件，您可以构建出漂亮的Web应用程序。
- 但是，如果您想要精美的JavaScript行为，您需要编写一些JavaScript代码
- JSF在客户端或服务器端跟踪当前UI状态。这是网络流量或服务器内存之间的权衡。
简历：
- GWT更适合需要最佳客户端性能的Web应用程序（例如Gmail）。它很容易编写自定义组件（您编写Java），并且由于服务器端只是服务层，因此您可以完全无状态地在服务器端运行。
- Miguel Ping
1
你忘了告诉他永远不要使用GWT或任何其他Java客户端框架，因为这些框架往往对开发人员非常痛苦。我强烈建议使用自己的HTML/CSS/Javascript而不是用Java代码构建自己的HTML页面，然后将所有内容编译成Html/Js。 - Yassir Khaldi
18
我只使用过JSF，所以无法对其他技术提供反馈，以下是我的JSF使用体验。在我看来，当我们从JSP中的JSF转换为facelets中的JSF时，生活变得轻松得多，所以我将重点介绍facelets。此外，Seam和JSF似乎并不是互斥的。
优点：
- 创建facelets xhtml组件很简单，这有助于重复使用。
- 使用内置标记（如ui：insert，ui：include和ui：decorate）具有相当好的模板能力
- 通过faces-config可以简单地访问Spring bean
- 基于XHTML，因此对Java不熟悉的Web开发人员仍然可以有效
- tomahawk / trinidad中提供了良好的小部件库
缺点：
- 仅支持Post请求。这可能会使书签功能困难。
- 不像GWT那样内置ajax，但如果与Seam一起使用，则可能会解决此问题
我绝不是JSF / Facelets方面的专家，所以我肯定会错过其他方面。希望其他人也能详细阐述。
JSF 2.0更新：
- 具有更好的重复使用功能，具有复合组件
- 2.0的小部件库包括primefaces和mojarra scales
- 允许get请求和书签功能
- 具备内置Ajax支持
- 有关JSF 2的更多信息，请参见http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/
- digitaljoel
9
1Seam 让使用 JSF 的 GET 请求和拥有可书签的 URL 变得简单。 - Peter Hilton
1如果你在stackoverflow上搜索“wicket”，你会发现很多关于这些Web框架的讨论，这可能会对你有所帮助。特别是https://dev59.com/53VD5IYBdhLWcg3wTJvF和https://dev59.com/-nRB5IYBdhLWcg3wuZQ1。 - digitaljoel
1我对SEO了解不多（我猜你是指搜索引擎优化），但我想AJAX / JavaScript可能会干扰它。然而，重点在于如何传播内容，因此我认为根据您的应用程序和演示方式，您可以成功地使用其中任何一种。在我的有限经验中，我认为完整的GWT应用程序可能是最难的SEO。 - digitaljoel
@digitaljoel JSF2 包括对 GET 请求的支持，类似于 JSF1.2 + Seam 2 支持 GET 请求的方式。使用 Seam 2 而不是 JSF 的想法有点奇怪（我从它发布以来一直在使用 Seam）。在我看来，Seam 补补 JSF 1.x 中的大部分重要漏洞。JSF2/CDI 已经解决了大部分问题，我相信你也知道。 - Joshua Davis
是的，如果不使用Seam，JSF 1.x相当痛苦。我已经开始使用JSF2/CDI进行一些新项目的开发，发现它非常易于使用。 - Joshua Davis
显示剩余4条评论
16
非常感谢Wicket团队的努力，让这场讨论保持清醒。作为一个Wicket用户，我很喜欢它。我的主要原因是：
- 它是一个组件框架。与完整页面相比，我喜欢使用组件。
我可以让设计师在模板和页面上工作，而我则专注于Java部分
没有什么新的东西需要学习。它只是“Java和HTML”
- 我喜欢它的Ajax回退机制。当浏览器没有javascript支持，特别是在移动设备上时，它会回退到纯html，所有功能都能正常使用。
- 它不需要XML配置，这是一个优点
- 它支持我在Web应用程序中所需的一切，例如验证、国际化、后退按钮支持和RESTful URL等。
我以前的经验是GWT和JSF 1.0
- joshua
10
Seam是一个应用框架，不是真正的演示层。它最初是为了使JSF变得更加容易，但已经发展成为一个更通用的依赖注入框架。
我认为您可以使用Seam与JSF、Wicket和GWT。JSF支持是主要的且很好的；我不确定其他两个受到多少支持。
由于您的标准重点似乎是您技能的市场营销能力，因此我建议尝试通过Facelets使用Seam和JSF。JSF是一个被广泛接受的标准，如果您使用Facelets，它实际上很愉快。您可以通过Richfaces和Ajax4jsf获得流畅的AJAX功能。Seam正在通过JCP进行更多或更少的标准化。
- recampbell
5
有意思。Richfaces 是否将您绑定到 JBoss？ 您还建议使用 Facelets - 我没有看到提到它的任何招聘信息 - 这是因为它相对较新还是因为招聘信息更有可能只提到 JSF？ - karl
JSF最初在JSP中使用，然后在facelets中使用，但我认为JSF团队更偏爱facelets。这在JSF 2.0规范中很明显，该规范列出了facelets相对于JSP的优势。 - digitaljoel
1Karl - Richfaces应该可以在支持JSF的任何容器中使用，据我所知没有JBoss依赖。至于工作职位发布方面，我个人会避免任何需要JSP的工作；Facelets才是正确的选择。;-) - recampbell
1忘掉JSP吧。Facelets是Seam（和JSF 2.0）中的默认视图技术，因此Seam通常意味着Facelets，尽管有一些Wicket支持。 - Peter Hilton
我一直不太喜欢使用richfaces。如果我可以使用XCSS而不包含控件套件中使用的任何“基本” XCSS，那就太好了，否则它在教育机构中的起源显而易见。它会妨碍你自由地利用现有的HTML和CSS专业知识。除此之外，对于一个好答案，点赞+1。Seam Remoting“只是工作”，并且推荐用于AJAX。 - Simon Gibbs
7
我的经验按时间顺序如下：
原始Servlet - （是的，很辛苦，但那时候还很早，我们都非常热心！）
JSP - 当它出现的时候，我觉得它是最棒的（如果我们只知道 ;)）
Echo - 令人敬畏的框架，但不适用于需要搜索引擎友好的页面（与GWT相同的问题）
Wicket - 令人敬畏的框架 - 开发人员完全理解面向对象的概念（不像JSP和许多其他框架），并将所有通常的OO细节应用于此框架。如果您欣赏“可重用性”，如果您欣赏封装性，如果您欣赏关注点分离，并且如果您喜欢将模型绑定到UI代码而不必担心对象编组和其他类似的难看东西，那么这就是适合您的框架！
- Volksman
1
2我从来没有走过纯servlet的路线（不是为了HTML渲染），所以对此不能评价。但是我有一些构建Wicket应用程序的经验，现在必须使用JSF。见鬼，我多么希望回到Wicket。对于某些人来说，使用JSF可能更容易，但我更喜欢Wicket背后的清晰和简单原则。简单的事情很容易做，更复杂的任务也不难，因为API提供了覆盖默认行为的钩子。 - bert
3
在长期情况下，我建议使用由Sun规范支持的技术。这已被证明可以提供多种实现选择（通常还包括开源实现），而且行为往往非常明确定义。
这将有助于您在维护情况下，希望您的代码最终也会如此。编写良好的代码永远存在：）
在这种特定情况下，我建议使用JSF。我只尝试过1.1的Apache实现，但它对JSP来说很痛苦。我们很快就要进行修订 - 我期望研究一下使用facelets的JSF。
这将有助于您在维护情况下，希望您的代码最终也会如此。编写良好的代码永远存在：）
在这种特定情况下，我建议使用JSF。我只尝试过1.1的Apache实现，但它对JSP来说很痛苦。我们很快就要进行修订 - 我期望研究一下使用facelets的JSF。
- Thorbjørn Ravn Andersen
11
4我认为选择一个Sun规范并不像选择那么多的事实标准（如Struts，Hibernate，Spring，Log4j等）那样重要，因为许多这些标准都是Sun规范，但由于它们的强大和实用性而被广泛采用。如果有什么区别，那就是这些成功的项目后来证明了标准的必要性，而这在JSF上显然并不是这样。 - Brian Laframboise
我给你点赞。我选择了Seam 2/JSF 1.x，因为我相信最终Seam会改变JSF。这也随着JSF2/CDI的出现得以实现。 - Joshua Davis
你会建议自己仅使用由Sun规范支持的技术吗？不要误解我的意思，我很喜欢Sun（当它还存在时），但我假设你的政策意味着你和其他人一起跟随Sun发布（释放）的最荒谬的Java技术走向悬崖：EJBs - EJBs是你应该质疑一切并且不管是谁生产它都要做出假设的原因。 - Volksman
@ThorbjørnRavnAndersen 在你无知的侮辱之后，我感到无语...嗯，不完全是：显然你是一个在没有先动脑筋的情况下就做出巨大假设的人 - 我喜欢Java EE - 过去20年来，我一直在使用它构建系统，为客户赚取了数百万美元。仔细阅读我所说的内容：我正在指出盲目使用由Sun规范支持的所有东西的建议，以EJB 1作为可能是有史以来最糟糕的Java技术的例子。你不需要成为一个拙劣的工匠才会讨厌EJB - 你只需要没有前额叶切除术就可以讨厌它。 - Volksman
@Volksman，你还没有理解重点。即使某项技术绝对棒极了，架构师可能会选择其他不那么棒的技术，因为考虑因素比一个狭隘开发者在他的小世界里所喜欢的要广泛得多。但是，我来试试看，如果一个解决方案的期望寿命是几十年，你会推荐什么？你10年前会推荐什么？20年呢？ - Thorbjørn Ravn Andersen
显示剩余6条评论
1
如果你只考虑就业市场，那么你应该选择JSF。但是，我相信未来的RIA属于GWT和类似的客户端技术。
我认为GWT最明显的优点是，它比像JSF、Wicket等服务器端呈现层技术更具可扩展性。因为服务器不需要存储客户端状态，而且客户端CPU功率也被利用了。这是一个巨大的好处，你不需要在服务器计算机之间序列化客户端状态来实现容错系统。
- Gursel Koca
2
现在已经过去了6年多，你还认为GWT拥有未来吗？ - Mike Braun
不，我不这样认为。JavaScript 已经主导了市场。但是我的预见是正确的；客户端技术已经主导了市场。GWT 的复杂性使大多数开发者感到害怕。 - Gursel Koca
1
我曾经广泛使用Wicket和GWT。但从未真正喜欢过Wicket。
我的博客谈到了这个问题 http://salk31.blogspot.com/2009/07/wicket-ajax.html
今天看到GWT 2.0 uiBinder，让我想起在Wicket中必须将XML组件树与Java创建的组件树匹配是多么烦人。对我来说，GWT的解决方案看起来好得多。
我已经一年多没有使用Wicket了，也许他们已经修复了很多问题，但考虑到现代浏览器和JS支持，我不明白为什么要在服务器上做所有这些事情（我知道，我知道数据本地化）。
- salk31
1
这取决于您对知识产权的重视程度。使用Wicket，您的代码/IP都将安全保留在服务器端。如果您不是特别关注知识产权，那么当然可以用JS编写大部分UI代码，并通过非编译、易于反向工程的JavaScript将其全部发送到浏览器中，让竞争对手抄袭。不要误解，Wicket充分利用JS来创建高效、响应迅速的交互式UI，但不会暴露您的域模型或算法。 - Volksman
1
我知道有些晚了，但现在已经有很多关于框架的比较了，尤其是这个，在2010年Devox会议上发生的。
http://www.devoxx.com/display/Devoxx2K10/Comparing+JVM+Web+Frameworks
这应该能帮助你做出选择 :)
- Jean-Rémy Revy
1
我最开始使用JSF（1.1和1.2），但是它非常痛苦，所以我决定在下一个项目中改变。我进行了一些研究，然后决定尝试Wicket，结果非常愉快。 我也尝试过JSF 2，但还是一样。
两者都是组件框架，但是Wicket的东西很容易，而JSF则是一团糟。
Wicket优于JSF：
- 在Wicket中，HTML就是HTML。JSF有自己的标记语言。h:dataTable（用于表格）是无意义的。相信我，Sun工程师在设计时可能喝醉了。
- 在Wicket中，像安全性这样的事情
- 使用JSF时，导航栏会显示先前的URL。真的很奇怪。
- 对我来说，JSF似乎非常沉重，而像Rich或Prime这样的库更加如此。
- 有时，似乎不可能知道正在发生什么。你总是最终对着电脑大喊，因为你不知道JSF在做什么。
JSF优于Wicket：
- 在Wicket中，您将编写更多的Java代码（与HTML绑定）。至少，您的IDE将提供重构和验证支持。
- Wicket中的资源管理有点棘手。
- JSF有更多的文档和支持。
一个常见的缺陷是会话大小是个问题（因为图形组件存储在其中）。
总的来说，如果您只需要在Wicket和JSF之间做出决定，对我来说毫无疑问，选择Wicket。
- polypiel
4
HTML == Wicket中的HTML吗？是的，但不要忘记您需要在Java中镜像整个组件树，并确保其保持同步。这是一个很大的代价，因此这个所谓的好处非常具有误导性。在JSF中，您只需在视图模板上定义一次树即可。Facelets还具有HTML模式（请参见Facelets的维基百科页面），而JSF 2.2具有“传递元素”。 - Mike Braun
导航栏显示以前的URL？那只有在没有重定向的情况下使用导航规则时才会出现。但是1.您不必使用导航规则，2.您应该使用PRG模式（发布重定向获取）或基于纯get的链接。您的经验似乎基于古老的JSF版本。 - Mike Braun
JSF 与 Wicket 相比，谁更占用资源？开玩笑吧... JSF 比 Wicket 使用更少的资源（CPU 和内存）。可以查看像“全球等待”这样的基准测试。再次说明，你的经验似乎是在使用古老的 JSF 版本，它们还没有部分状态保存功能。 - Mike Braun
@MikeBraun 我从未觉得在Java中镜像组件树对Wicket来说是一个重大负担。有一个可以被覆盖的ComponentResolver接口。我们使用它来允许标记语言虚拟驱动组件的组装。我们提供了所有可用组件的列表，然后标记语言可以随意更改，并且相关组件会按照标记语言的指示添加，因此提供与标记语言匹配的Java组件图完全是自动的。此外，Wicket 7现在添加了组件排队功能，使管理Java端变得容易。 - Volksman
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接