帮助选择基于java组件的web框架答案

【问题标题】：Help selecting java component-based web framework帮助选择基于java组件的web框架
【发布时间】：2011-06-18 15:46:55
【问题描述】：

我有兴趣尝试和学习基于组件的 Web 框架。目前，我只有 Spring MVC 和 Grails 等基于动作的框架的经验。我正在选择：JSF 2.0、Wicket 和 Tapestry。

感谢您在理解方面的帮助：

这三个中哪个“最容易”学习？
这三个中哪一个拥有最好/最多的可用资源（书籍、网站、书籍）？
三者中哪一个在代码（过去和未来的兼容性）和社区方面最稳定
这三个中的哪一个提供的性能最高/资源（cpu 和内存）消耗最少？

谢谢！

【问题讨论】：

我更喜欢 JSF 2.0 - 这是一个标准，它有很多组件（RichFaces、PrimeFaces 等）
虽然我不是JSF 2.0的粉丝，但如果我有这三个选择，我会选择它。但是你应该知道 JSF 的性能是最差的。
@Gursel：建议另一个您喜欢的基于组件的 MVC 框架。另请发布确认性能声明的在线资源（JSF/Wicket/Tapestry 的性能比较）。
@Bozho：您能否详细说明我应该进一步研究哪个组件（RichFaces、PrimeFaces、IceFaces）。 @Gursel：如果选择不受限制，你会推荐什么？
@Gursel Koca - GWT 几乎没有任何服务器端部分。性能是在哪里测量的？ @JacJ122 - 我在同一个项目中同时使用了 RichFaces 和 PrimeFaces。所以它不是一个“或”。两者都很好。

标签： java jsf wicket tapestry

【解决方案1】：

我个人偏爱 Tapestry。但是，程序员的效率是我的主要标准。如果这些对您来说是最重要的标准，那么您可能希望使用 JSF 2.0 之类的其他标准。

我发现 Tapestry 相当容易学习，但我有 WebObjects 的背景。例如，如果您只进行过 Struts 编程，您可能会发现它有点困难。
大多数人通过邮件列表学习 Tapestry。社区非常有帮助，档案也非常有用。 (http://tapestry.markmail.org) 刚刚在http://tapestry.apache.org 上大力推动真正改进Tapestry 用户文档，结果非常出色。如果您想了解书籍的数量，请在亚马逊上进行搜索。 JSF 2.0 和 Spring MVC 可能拥有最多的书籍。
Tapestry 5 在允许您将应用程序从 5.0 升级到 5.1 到 5.2 方面非常稳定，而且问题很少。一些（声乐）人抱怨他们无法将 Tapestry 4 应用程序升级到 Tapestry 5。就我个人而言，我宁愿处理一个起点清晰并建立在以前版本的经验之上的框架而不是以前版本的代码库。如果您的目标是选择一个包含大量遗留代码的框架（例如，如果您想通过咨询来帮助公司处理现有代码），那么您可能应该考虑 Struts。
李>
性能通常在很大程度上取决于你想用框架做什么，所以我不能给你一个具体的答案。我还没有看到任何框架比较，其中所有代码都是由专门研究该特定框架的人编写的。这意味着测试非常基础，以至于它们无法告诉您任何有关实际实践的信息，或者它们足够复杂，以至于结果偏向于测试人员最有经验的框架。

除非您尝试创建类似 eBay 的东西，否则您可能会让这些框架中的任何一个表现良好。考虑到硬件有多便宜，您最好选择能够为您提供最佳程序员效率的硬件。

【讨论】：

Tapestry 自 2011 年以来发展得更好。特别是客户端部分。

【解决方案2】：

我认为，您应该从检查 Matt Raible 最近编译和更新的 java web 框架枪战开始：

这里是比较的直接链接：http://spreadsheets.google.com/pub?key=0AtkkDCT2WDMXdC1HOEtnUHpCejJMbUhGeGJWUmh5dVE&hl=en&output=html
这是一个关于它的故事http://raibledesigns.com/rd/entry/how_i_calculated_ratings_for

就个人而言，我是 Tapestry 的用户，从版本 3 开始 :) 并且已经使用了所有这些。虽然让 Tapestry 4 向后与 3 不兼容，然后 4.1 与 4 不兼容，最后 5 与其余的不兼容，这对开发人员来说非常困难，但我认为这是最好的。 Tapestry 5 在各个方面都比任何以前的版本都好，现在贡献者继续添加酷炫的功能以及核心改进，而完全不破坏向后兼容性。

我最喜欢 Tapestry 5 的地方在于，您几乎可以用自己的实现替换框架的任何部分 - 它非常灵活且可定制。

让我感到温暖的另一件事是，Tapestry 的贡献者非常专注于通过实现各种漂亮的组件/功能来提高我（作为开发人员）的工作效率。

但这些只是我的情绪，毕竟我想说，谁吃的记忆力少，谁的书多都没关系。重要的是哪一个能让你/你的团队更快乐、更有动力、更有效率，而找出这一点的唯一方法就是尝试每个人:)

【讨论】：

【解决方案3】：

唯一正确的答案是：在一些小示例应用程序中尝试所有这些。但根据我的喜好，我会选择 Tapestry 5。

广告 1。它相当容易学习。随着时间的推移，它获得了足够的材料来学习如何使用它。用户列表也很棒，人们反应迅速。

广告 2。由于 JSF 是 Java 标准，因此 JSF 可能最终会在学习材料类别中获胜。

广告 3。我不会将 Tapestry 5 视为向后不兼容。它与 t4 和 t3 不同的框架。它只是碰巧有相同的名字；）而且 t5 是稳定的，并且在 2 年多的时间里都在尊重以前的版本。

不过，JSF 也将赢得这一胜利。它是java标准，和java一样，向下兼容100年。

广告4。这取决于谁测试应用程序以及他如何实现功能。但是我记得 JSF 是最后一个。

T5 的好处是任何组件库都将与任何其他库兼容。对于 JSF 来说，这可能不是真的。我相信 primefaces 不能与 icefaces 或任何其他实现结合使用。

但是在这 3 个中，我在实际项目中只使用了挂毯。 Wicked 看起来不错，但我更喜欢 Tapestry。至于 1.2 之后的 JSF，我不想尝试新版本，直到我不得不这样做。 Tapestry 也是非常适合我需要的框架。

还要想想你的老板。他们总是想要带有标准徽章的东西。这就是为什么选择最旧版本的 Struts、java 1.4 和 JSF 总是一个好主意：/

问候迈克尔

【讨论】：

我没有任何基于组件的框架的经验，我总是使用基于动作的框架进行开发；但当我阅读文档时，我更喜欢 Tapestry。我看到的唯一问题是它的文档，它有很多魔力，你遇到过什么问题吗？你怎么能找到解决办法？例如关于动态表单，或动态验证器和 ....
另一个注意事项，Tapestry 5 在字节码操作方面做了很多魔法（其他框架没有），你遇到过任何问题和错误吗？调试您的应用程序时是否有任何问题？
嗨，Amir，我使用 T5 已经有一段时间了，除了逐步学习曲线，从来没有遇到过问题。现在我正在努力使用 T5.4，但它是 alpha 版，我自己做了很多 .js 魔术，所以这只是一个深入的潜水 4 我（我在 .js 方面做得不好)。
至于调试：使用开发模式，从 T5.3（我猜）开始，所有字段都完全可见，您可以毫无问题地调试。在 prod 模式下，我认为它可能更麻烦，但它确实有效。动态形式：是的，可能更难，但有一些例子如何让它工作。您使用不同的工具，但一切都在那里。如果你必须做一些不寻常的事情，那么你只需创建一个组件，然后可以在整个应用程序中重复使用它。
在 100% 投入 T5 之前，您可以查看主要贡献者之一 Igor Drobiazko 所著的一本书。 IT 涵盖了 T5 的大部分内容（我认为它跳过了与进行疯狂的 AOP 和字节码操作相关的“神奇”部分）。从中您将获得所有基础知识和所有问题的答案

【解决方案4】：

我会说 Wicket 或 Vaadin。

https://cwiki.apache.org/WICKET/wicket-reference.html

http://www.vaadin.com/

最容易学习：如果你知道摇摆，它会更容易理解。两者都有效。
Wicket 可能拥有比 vaadin 更多的资源。用户列表也很活跃，很有帮助。
两者都是相当成熟的项目。未来的兼容性是未来的事情，但我猜提交者将尽最大努力以最好的向后兼容性发布。
这只是猜测，并非基于实际性能测试：可能 wicket 会比 vaadin 做得更好。

最后一件事是，使用 vaadin 更容易获得酷/漂亮的 UI。

Tapestry，见以下链接：

https://stackoverflow.com/questions/1303438/why-did-you-stop-using-tapestry

【讨论】：

【解决方案5】：

这些是选择框架的有趣标准。通常你的实际编程经验会比有多少书更重要。 “易于学习”的标准可能有些意义，但如果一个框架需要多 10 小时的前期投资，但它每周可以为您节省 10 小时的编程时间，那么开始投资是非常值得的。

如果您真的想找到一个适合自己的方案，最好还是继续在多个不同的框架中编写一个小型应用程序。

这种方法的问题在于，除非您有时间至少部分精通每个框架，否则您的意见会根据您最熟悉的内容产生偏差。

【讨论】：

决定因素不仅仅是书籍的数量，而是学习的数量resources，因为这直接影响到框架的学习难易程度。理想情况下，我希望能够使用每个框架编写小型应用程序，但这仍然可能会导致我的“意见会根据 [我] 最熟悉的内容产生偏差。”这就是为什么我要从那些使用基于组件的框架的人那里寻找反馈/见解，从中我可以对我想首先尝试哪个框架（并且可能坚持使用）做出“有根据的猜测”。

【解决方案6】：

我花了一些时间阅读 Tapestry。我发现这比我之前想的要好一些。事实上，Tapestry 和 HybridJava 在方法上有很多共同点。这需要一些时间，但我希望稍后在这里给出更详细的比较。

【讨论】：

【解决方案7】：

首先（也是最重要的）那些声称它们是基于组件的框架实际上可能与组件的含义大不相同。在 Wicket 中是一回事，在 JSF 中是另一回事，而在 Struts 中则完全不同等等。您可以在 HybridJava 中找到最强大的 Web 应用程序组件定义。其他框架根本赶不上。

顺便说一句 - HybridJava 的学习比 Wicket 容易 5 倍 - 只需阅读大约 15 页。它的运行速度也非常快，运行时 jar 不到 19k。

【讨论】：

您还必须提防虚假声明，例如“最强大的组件定义”。我会坚持我的说法，即 Tapestry 是最高效的框架，并用具体的细节来支持它，包括实时类重新加载、最少的模板和代码，以及非常出色的异常报告，仅供初学者使用。是什么让组件“强大”？
@霍华德。我说的是组件的强定义，而不是强组件。 8-）实际上我建议比较各种框架中“组件”的定义是什么。这是关于从我们称为“组件”的一些单元构建 Web UI，因为我们希望这些单元提供代码的分解和重用。我还建议您作为 Tapestry 大师，用简短的语言告诉 Tapestry 中的“组件”是什么意思，但您没有这样做。如果你这样做了（如果你这样做了，我会很高兴），我们也许可以讨论这些组件如何比那些组件更好（更强大的概念）。
@tetsuo 我雇佣了 100 人并设置了实验 8-)。否则我可能会比较每种技术中 API 方法的总数和文档的大小。 HybridJava 全部在大约 20 页中进行了描述，API 大约有 20 个方法。否则，我请您尝试阅读这 15 页 8-)
Tapestry 组件履行 MVC 设计模式中的控制器角色。因此，它们是呈现页面内容的焦点（作为完整页面呈现的一部分，或者在 Ajax 场景中作为部分页面呈现）。渲染还包括次要方面，例如 JavaScript 生成（为客户端编写 JavaScript 初始化，以及导入 JS 库）。作为控制器，组件还负责响应用户交互；在 Tapestry 术语中，响应客户端事件（例如链接点击或表单提交）。
Tapestry 组件具有丰富的基础架构来实现这些关注点，遵循 Tapestry 让框架适应用户代码的一般方法，而不是相反......因此命名约定和/或注释，以及次要对象和服务的注入。因此，尽管组件可以被描述为“具有参数、呈现自身（在代码中和/或使用模板）、响应事件”，但这是一个非常结构化的定义，在实践中，它更丰富。跨度>