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

Question

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

我很好奇是否有人可以权衡各种Java表示层技术的优缺点。如果你只和一个人一起工作，说出你为什么喜欢或讨厌它。如果你和几个人合作过，那么就给出你们对彼此之间如何叠加的印象。

我们正在考虑的技术是：

• ICEfaces的
• JSF（没有IceFaces）
• GWT（Google Web Toolkit）
• 检票
• 挂毯

如果我在列表中遗漏了任何内容，请告诉我。

谢谢！

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，所以我没有 make 它执行ajax，它只是使用了GWT。
2. 客户端与服务器端代码的分离很好。
3. 我可以使用junit
对我的客户端代码进行单元测试
4. 它可以让你构建清晰，活泼的应用程序，主要是因为它是ajax。

我不喜欢的事情：

1. 有些东西没有按预期工作。例如，我见过点击事件未按预期触发的情况，所以我不得不做一个解决方法。
2. 自动部署到在eclipse中运行的tomcat有时会停止工作，我无法弄明白为什么。

Answer 3

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

Answer 4

简而言之：

= JSF =

优点：

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

CONS：

• 重量很重，包括CPU /内存和学习曲线;
• 当某些内容无法按预期工作时，很难调试

= WICKET =

优点：

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

CONS：

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

Answer 5

Stripes怎么办？

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的比较：Difference between Apache Tapestry and Apache Wicket。