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

Question

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

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

我们正在考虑的技术是：

• ICEfaces的
• JSF（没有IceFaces）
• GWT（谷歌网络工具包）
• 便门
• 挂毯

如果我遗漏了我的清单中的任何内容，请告诉我。

谢谢！

Answer 1

我的意见对Wicket有很大的偏见，因为我曾经多次使用JSP矿山后一直使用它。

Wicket PROs：

• 真正分离布局和代码。
• 基于组件，意味着站点元素的高可重用性; 例如，您可以使用自动标签和CSS样式以及所有内容创建美化形式，只需在组件的构造函数中更改它的DAO对象，它就可以在另一个项目中完全重用。
• 对Ajax，Portlets和各种框架的一般直接开箱即用的优秀支持，更重要的是它不依赖于除slf4j / log4j之外的任何其他工作，一切都是可选的！

Wicket CONs：

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

随机CONs :(也就是说，我没有使用，但这些是我听到的opionions和/或事情）

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

Answer 2

我已经将GWT用于几个小项目。 以下是我喜欢的一些内容：

1. 它的默认AJAX，所以我没有让它做AJAX，它只是使用GWT走过来。
2. 它与客户端代码的良好分离。
3. 我可以使用junit对我的客户端代码进行单元测试
4. 它可以让你构建清晰，活泼的应用程序，主要是因为它是ajax。

我不喜欢的事情：

1. 有些东西没有按预期工作。 例如，我见过点击事件未按预期触发的情况，因此我不得不做一个解决方法。
2. 自动部署到在eclipse中运行的tomcat有时会停止工作，我永远无法找出原因。

Answer 3

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

Answer 4

简而言之：

= JSF =

优点：

• 组件架构;
• 许多图书馆和工具;
• 有点好的IDE支持

缺点：

• 重量级，无论是CPU /内存还是学习曲线;
• 当某些东西不能按预期工作时，很难调试

= WICKET =

优点：

• 轻巧;
• 合理的模板系统;
• 好的教程;

缺点：

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

Answer 5

条纹怎么样？

Answer 6

我的选择是Wicket 。 使用它并提供出色的可重用性。 它拥有最具活力的论坛/邮件列表之一。 作为一个问题，它将在几分钟内回答。 它对AJAX提供了出色的支持。 归因于Wicket的一个常见缺点是陡峭的学习曲线。 那些是现在不再有价值的老年弊端之一。

JSF：最好远离它。 另一个开发了JSF项目的团队现在正考虑在我们取得成功后转向Wicket。

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

Answer 7

我想知道你是否有一个与Web客户端不同的服务层，这是Web控制器只是为了完成工作而调用的东西。

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

Answer 8

请参阅我对Wicket和Tapestry 5的比较： Apache Tapestry和Apache Wicket之间的区别 。