各种 Java Web 表示层技术的优缺点答案

【问题标题】：Pros and Cons of Various Java Web Presentation Layer Technologies各种 Java Web 表示层技术的优缺点
【发布时间】：2009-02-11 20:13:43
【问题描述】：

我目前正在开发一个大量使用 JSF 和 IceFaces 的网络应用程序。我们已经讨论过转移到另一个表示层，我想我会把讨论带到 SO 中，看看专家们是怎么想的。

我很好奇是否有人可以权衡各种 Java 表示层技术的优缺点。如果您只与一个人合作过，请说出您喜欢或讨厌它的原因。如果您曾与多个合作过，请给出您对它们如何相互叠加的印象。

我们正在考虑的技术是：

冰面
JSF（没有 IceFaces）
GWT（谷歌网络工具包）
检票口
挂毯

如果我的列表中缺少任何内容，请告诉我。

谢谢！

【问题讨论】：

标签： java jakarta-ee presentation-layer

【解决方案1】：

我的观点对 Wicket 有很大的偏见，因为我在多次被 JSP 地雷绊倒之后已经使用了一段时间。

Wicket PRO：

真正的布局和代码分离。
基于组件，这意味着站点元素的高度可重用性；例如，您可以创建带有自动标签和 CSS 样式以及所有内容的美化表单，并且只需在组件的构造函数中更改它的 DAO 对象，它就可以在另一个项目中完全重用。
对 Ajax、Portlet 和各种框架等东西的出色支持通常直接开箱即用，更重要的是它不依赖于 slf4j/log4j 以外的任何东西来工作，一切都是可选的！

检票口缺点：

总体而言，开发过程有些混乱，Wicket 泛型现在有点混乱，尽管它们在 1.4 中已经被清理了很多
某些组件（如Form.onSubmit()）需要大量子类化或匿名方法覆盖，以便轻松注入行为。这部分归功于 Wicket 强大的基于事件的设计，但不幸的是，这也意味着 Wicket 很容易使代码混乱。

随机缺点：（也就是说，我没有使用过，但这些是我的意见和/或我听说过的事情）

GWT 是基于 JavaScript 的，这对我来说听起来很愚蠢。主要问题是它让我想起了太多的 JSP:s 及其自动生成的类，这太可怕了。
Tapestry 没有以一种可以在两者之间轻松验证的方式正确分离标记和代码，这将在未来引起问题。

【讨论】：

Esko，我同意你对 JavaScript 的厌恶，但你可能想看看 Douglas Crockford 的“JavaScript: The Good Parts”。此外，当提到 JavaScript 时，使用 JQuery 可以抑制我的呕吐反应。
谢谢，我只是把书名写在便利贴上，所以我最终会去看看。哦，Wicket 当然通过 Wicket Stuff（组件孵化器子项目）对 jQuery、mootools、dojo 和 scriptaculous 有很好的支持。
Tapestry 5 让您将标记和代码分开，但不像 Wicket 那样强制执行。
确实如此，但是 Wicket 的强项实际上是在执行它，它不会让开发人员在真正不应该允许开发人员偷懒的方面偷懒。

【解决方案2】：

我在几个小项目中使用过 GWT。以下是我喜欢它的一些地方：

默认情况下它是 ajax，所以我不必制作它做 ajax，它只是使用 GWT 附带的。
它很好地将客户端代码与服务器端代码分开。
我可以使用 junit 对我的客户端代码进行单元测试
它可以让您构建清晰、快速的应用程序，主要是因为它是 ajax。

我不喜欢的东西：

有些事情没有按预期工作。例如，我曾看到点击事件未按预期触发的情况，因此我必须采取一种变通方法。
自动部署到在 Eclipse 中运行的 tomcat 有时会停止工作，我永远无法弄清楚原因。

【讨论】：

【解决方案3】：

我要问的最大问题是为什么要更改表示层？这是一个非常昂贵的成本，我可以看到一种技术的好处超过其他技术的成本与改变成本一样多......

【讨论】：

好问题。我们对 IceFaces 的不满源于 a) 来自地狱的神秘肉异常——JSF 生命周期特有的问题，b) 这里的许多人认为它沉重而缓慢，以及 c) 社区支持不足。我们正在考虑对一个新项目进行更改，而不是我们现有的应用程序。
如果是新项目就好了。我也很好奇你对 IceFaces 的反应，因为我之前也考虑过。当它第一次成为开源时，它似乎是一个非常有趣的解决方案。但我从未在完整的应用程序上尝试过它......非常有趣。
IceFaces 的最大优点是它可以很容易地构建一个支持 AJAX 的界面。它通过隐藏很多复杂性来做到这一点。但是，当然，有时您想深入了解一下，而 IceFaces 使这变得比需要的更困难。（续...）
例如，如果您在一个 DIV 上设置一个 ID，IceFaces 的渲染阶段会使用您刚刚添加的名称填充该 DIV 下每个单个组件的 ID。我们的网站上有一些小的 Javascript 效果，所有这些都因此而经常中断。此外，它不能很好地与 JQuery 配合使用。
有趣...那么性能呢？我总是对拥有更多流量的大型网站感到好奇。

【解决方案4】：

简而言之：

= JSF =

优点：

组件架构；
许多库和工具；
IDE 支持不错

缺点：

在 CPU/内存和学习曲线上都很重；
当某些事情没有按预期工作时，很难调试

= 检票口 =

优点：

轻量级；
合理的模板系统；
很好的教程；

缺点：

参考文档的组织性和深度不如教程好；
开发团队遇到了一些严重的困难，特别是在成为和孵化项目时。这导致对框架的重要方面的混淆，当时我因此不得不切换到另一个框架......

【讨论】：

当时我觉得它很轻……嗯，至少比 JSF 轻

【解决方案5】：

Stripes 呢？

【讨论】：

【解决方案6】：

我的选择是 Wicket。已经使用过它，并且具有出色的可重用性。它拥有最活跃的论坛/邮件列表之一。作为一个问题，它会在几分钟内得到回答。它对 AJAX 有很好的支持。归因于 Wicket 的常见缺点之一是陡峭的学习曲线。好吧，这些都是旧时代的弊端之一，现在已经没有任何价值了。

JSF：最好远离它。另一个在 JSF 上开发项目的团队现在正在考虑在我们成功之后转移到 Wicket。

@Megadix：就像你说的文档一开始很差，但现在没有了。 Wicket 的开发人员编写了一本名为 Wicket in Action 的优秀书籍。网站上提供的示例代码也是一个很好的开始和学习的地方

【讨论】：

【解决方案7】：

我想知道您是否有一个不同于 Web 客户端的服务层，Web 控制器只需调用它来完成他们的工作。

如果这样做，则可以将 Web UI 技术的选择与后端解耦。如果它作为合同优先的 Web 服务公开，您可以让不同的应用程序共享它。只要您的客户可以发送和接收 XML，他们就可以与您的服务进行交互。想要切换到 Flex？不用担心 - 将它指向服务并呈现 XML 响应。

【讨论】：

这是个好主意。我们的层在很大程度上是解耦的，虽然不是很强大的 SOA。而且，虽然我们在这里确实使用了 Web 服务，但我们的表示层和服务层之间的性能已经足以成为一个问题，我们这次可能不会朝这个方向发展。

【解决方案8】：

查看我对 Wicket 和 Tapestry 5 的比较：Difference between Apache Tapestry and Apache Wicket。

【讨论】：