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

Question

我目前正在使用大量使用JSF和ICEFACE的网络应用程序。我们已经进行了一些有关转移到另一个演示层的讨论，我认为我会将讨论融入其中，看看专家的想法。

我很好奇是否有人可以权衡各种Java演示层技术的利弊。如果您只与一个人一起工作，请说明为什么您喜欢或讨厌它。如果您与几个合作，请给人留下深刻的印象。

我们正在考虑的技术是：

• 冰面
• JSF（无冰面）
• GWT（Google Web Toolkit）
• 便门
• 挂毯

如果我缺少清单中的任何东西，请告诉我。

谢谢！

Answer 1

我的意见非常偏向于检票口，因为在绊倒JSP矿山太多次之后，我已经使用了一段时间了。

检票口专业人士：

• 布局和代码的真实分离。
• 基于组件，这意味着站点元素的高可重复使用性；例如，您可以使用自动标签和CSS样式以及所有内容创建漂亮的表单，并且仅通过更改组件构造函数中的DAO对象，它在另一个项目中完全可以重复使用。
• 对Ajax，Portlet和各种框架等事物的极大支持，通常直接直接开箱即用，更重要的是，除了Slf4J/Log4J以外，它不依赖其他任何东西，而是所有的可选！

检票口缺点：

• 开发对一般的事情有些困惑，而检票口仿制药现在有些混乱，尽管它们在1.4中被大量清洁了
• 一些组件（例如 Form.onSubmit()）需要大量的子分类或匿名方法覆盖以轻松注入行为。这部分是由于检票口强大的基于事件的设计，但不幸的是，这也意味着与检票口混合很容易。

随机缺点： （也就是说，我没有使用过，但是这些是我的选择和/或我所听到的）

• 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/记忆中 和 学习曲线;
• 当某事无法正常工作时，很难调试

=小门=

优点：

• 轻的;
• 明智的模板系统；
• 好教程；

缺点：

• 参考文档的井井有条和深度不如教程。
• 开发团队遇到了一些严重的困难，尤其是在进入和孵化项目时。这导致了框架的重要方面的混乱，当时我不得不切换到另一个框架...

Answer 5

关于什么 条纹?

Answer 6

我的选择是 便门. 。已经使用了它，并具有出色的可重复使用性。它拥有最充满活力的论坛/邮件列表之一。作为一个问题，它将在几分钟之内得到回答。它对Ajax有很好的支持。陡峭的学习曲线是通常归因于检票口的通常缺点。好吧，这些是老年弊端之一，现在不再具有价值。

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

@megadix：就像您说的那样，该文档一开始就很差，但不再是。有一本出色的书，名为《检票口》由Wicket的开发商撰写的。网站上提供的示例代码也是开始和学习的好地方

Answer 7

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

如果这样做，可以从后端切除Web UI技术的选择。如果它被视为合同第一Web服务，则可以拥有不同的应用程序共享。只要您的客户可以发送和接收XML，他们就可以与您的服务互动。想切换到flex吗？不用担心 - 将其指向服务并呈现XML响应。

Answer 8

请参阅我对检票口和挂毯的比较5： Apache Tapestry和Apache检票口之间的区别.