logo标签列表

Apache Tapestry和Apache Wicket之间的区别

javawicketweb-frameworkstapestry
47

Apache Wicket (http://wicket.apache.org/)和Apache Tapestry (http://tapestry.apache.org) 都是基于组件的web框架，与像Stripes这样基于动作的框架相反，它们都由Apache Foundation提供支持。两者都允许您使用Java中的组件构建应用程序。它们在我的看来非常相似。

这两个框架有什么区别？谁有两种经验？具体而言：

  • 它们的性能如何？状态处理可以定制多少？是否可以无状态地使用？
  • 它们的组件模型有什么区别？
  • 您会为哪些应用程序选择哪一个？
  • 它们如何与Guice、Spring、JSR 299集成？

编辑：我已阅读了两者的文档，并且我都使用过。这些问题不能从阅读文档中得到充分的答案，而是需要使用一段时间后的经验，例如如何将Wicket用于高性能站点的无状态模式。谢谢。

顺便提一下，我已经对我的答案进行了很多修订。 - Sergey
7
出于 Tapestry 每个主要版本都会被完全重写并且很少与旧版本向后兼容的原因，我个人建议避免使用它。 - skaffman
8
从版本5开始，这个问题不再存在了——版本5的构建考虑到了未来的可扩展性。 - Joel
8个回答
41

以下是我认为两个框架的相关差异：

  • Tapestry使用半静态页面结构，您可以使用条件和循环来实现动态行为。Wicket完全是动态的，您可以在运行时动态加载组件，替换它们等。这样做的后果是Tapestry更容易优化，而Wicket在使用上更加灵活。
  • 两个框架在执行效率方面大致相同，但Wicket依赖于服务器端存储（默认情况下是会话中的当前页面和过去页面在“第二级缓存”中）。如果这让您不舒服，请考虑您预计在高峰期有多少并发会话，并以每个会话约100kb进行计算（这可能有些保守）。这意味着您可以运行大约20k个并发会话，需要2GB空间，但由于您还需要将内存用于其他用途，因此请考虑15k左右。当然，存储状态的缺点是它只能在会话关联性良好时正常工作，这是使用Wicket时的限制。该框架提供了一种实现无状态页面的方法，但如果您正在开发完全无状态的应用程序，您可能需要考虑选择其他框架。
  • Wicket的目标是最大程度地支持静态类型，而Tapestry更多地关注节省代码行数。因此，使用Tapestry可以使代码库更小，这对于维护是有益的；而使用Wicket，则更多地采用静态类型，这使得使用IDE和编译器检查更加容易，也有助于维护。在我看来，两种方法都有其优点。

我已经多次阅读到人们认为Wicket很多时候通过继承工作。我想强调，您可以选择。存在一种组件层次结构，但Wicket还支持构造像IBehavior这样的组合（例如Wicket的Ajax支持是基于其上构建的）。除此之外，您还可以添加转换器和验证器到组件中，全局或甚至使用Wicket提供的某些阶段监听器作为横切关注点。

“...你的代码库可能更小，这对于维护来说是有好处的”-- 你确定吗？经验表明，通常情况下相反。对于相同的复杂度和相同质量的代码，冗长的代码通常比简洁的代码更易于维护。为了实现简洁性，你需要使用魔法和捷径。 - Laurent Grégoire
@IOranger，这确实可能是情况。这取决于如何支持“更小的代码”。并非所有的魔法都是坏的，但它们肯定会适得其反。 - Eelco
36

经过学习Tapestry 5后进行了修订。

Wicket的目标是试图使Web开发类似于桌面GUI。他们在内存使用方面做得非常好，但代价是HTTPSession的消耗。

Tapestry 5的目标是创建一个非常优化（对于CPU和内存）的组件导向的Web框架。

我真正遇到的大问题是回应“Wicket支持无状态组件！”这个论点时，会被告知“Wicket需要很多内存”。尽管Wicket确实支持无状态组件，但它们并不是“Wicket开发的重点”。例如，StatelessForm中的一个错误很长时间没有被修复-请参见StatelessForm - problem with parameters after validation fails。

  • 依我之见，在优化/微调Web应用程序参数之前，使用Wicket要容易一些。
  • 如果您已经编写过Web应用程序并想以请求处理为思考方式，那么我认为学习Wicket更难。
  • Tapestry 5会在您更改组件后立即重新加载组件类。两个框架都会重新加载组件标记。
  • Wicket强制分离标记/代码，而Tapestry 5只是为您提供了这种能力。在Tapestry 5中，您还可以使用更简洁的语法。但是，这种自由需要采取更多的预防措施。
  • Wicket的核心更容易调试：用户组件基于继承，而Tapestry 5用户组件基于注释。从另一方面来说，这可能使得将来转换到Tapestry的版本比转换到Wicket的版本更容易。

不幸的是，Tapestry 5教程并没有强调像“t:loop source =”1..10“…”这样的Tapestry代码示例可能是一个不好的实践。因此，如果您的团队不是非常小，那么应该付出一些努力编写Tapestry使用惯例/最佳实践。

我的建议:

  • 当您的页面结构非常动态且您可以承担每个用户10-200 Kbs的HttpSession内存消耗（这些是粗略的数字）时，请使用Wicket。
  • 在需要更有效地使用资源的情况下，请使用Tapestry 5。
特别是如果您的团队中有一些初级/纪律不够严谨的程序员 :) - Sergey
我明白了。嗯，这并不完全是代码，因为你仍然必须使用组件，而循环只是其中之一。但你说得对，我也更喜欢仪表板语法，也许<t:...>语法应该被省略掉。 - Henning
2
@chillenious，在Tapestry 5中，您可以选择是否广泛使用内存。据我了解，在Wicket中，您只能玩一下用户会话的存储位置。 - Sergey
4
为了证明我的观点，可以看一下这个链接：http://ptrthomas.wordpress.com/2009/09/14/perfbench-update-tapestry-5-and-grails/即使你认为这是一个有偏见的微基准测试（我认为不是），也不要假设什么，而是进行测量。那里的结果（Wicket更快且占用的内存更少）与我自己进行的各种基准测试以及其他人多年来所听到的基准测试一致。虽然我不会说差异足以选择框架，但可以选择适合你风格的框架。 - Eelco
2
至少在Tapestry 5中，你可以选择是否广泛使用内存。据我所知，Wicket只能玩弄用户会话的存储位置。你可以选择存储任何内容。这是一个非常灵活的框架，特别是因为它让开发人员负责对象的创建等等。我们只是不支持客户端状态保存，主要是因为当我们正在实施它时，它变得非常低效（就像ASP.NET、JSF等一样），我们认为这不值得我们的努力。 - Eelco
显示剩余8条评论
10
1
很想看到使用Tapestry 5的类似比较。 - jnichols959
抱歉，该文章仅涵盖Tapestry 4，因此它现在已经不相关了。 - Bob Harner
@jzd http://web.archive.org/web/20131011174338/http://www.ibm.com/developerworks/java/library/os-tapestrywicket/index.html?ca=drs - valentin_nasta
1
1
请参见http://stackoverflow.com/questions/1303438/why-did-you-stop-using-tapestry - Stephan Eggermont
1

我认为Wicket是一个更简单易用的框架。

此外，Wicket允许通过IDE的热代码替换系统重新加载类。这是Wicket运行修改后的当前正在运行的应用程序类所需的全部内容。热代码替换有一些通常的限制，例如必须在调试模式下运行（Eclipse），不能更改类的结构方面（即类名、更改方法签名等）。

0
1
许多框架声称自己是最好的，但实际上没有一个证明自己是正确的。当然，Wicket 在某些方面的处理方式非常繁琐，但仅仅通过复制 Wicket 的优点并不能创造出更好的框架。此外，他们的快速入门比 Wicket 的第一步就要更加复杂。 - Esko
点击“快速开始”后，您可以使用Click（编写代码）。在Wicket快速启动后，您已经安装了wicket-感受到了区别吗？;-)Click不是Wicket的副本。它们在同一时间诞生，受Tapestry的启发。2Stephan：如果您喜欢Stripes，您会喜欢CLick，就像Stripes书的作者一样：http://stripesbook.org/blog/index.php?/archives/47-New-book-Getting-Started-With-Apache-Click.html - Andrej Fink
2
Wicket QuickStart是一个Maven POM创建器，Click的QuickStart相当于Wicket的“Hello World”@ http://wicket.apache.org/examplehelloworld.html。同时，Click似乎没有真正实现代码和标记的分离，这是Wicket最大的特点之一 - 实际上，Click使用Velocity作为HTML的模板语言。因此，尽管Click声称自己是组件导向的，但它并不是真正的组件导向，更接近于JSTL或Tapestry。此外，您显然在做广告，这让我对您的帖子感到不安。 - Esko
2
  1. 对我来说（例如像这个人http://www.assertinteresting.com/2009/03/why-i-prefer-stripes-over-wicket/），快速入门意味着更多一点（引用：“如果你阅读快速入门指南，仅仅3页左右，你就会基本上“get” Stripes）。
  2. 我不是那么纯粹主义者，在长时间使用“原始”的servlets+JSP，然后是servlets+Freemarker，再到SpringMVC+Freemarker之后，Click对我来说足够面向对象和组件化了。
  3. 我喜欢Spring和Freemarker。Click与它们两者一样有趣。
  4. 我与Click框架没有关联，我只是一个狂热的粉丝。
 - Andrej Fink
0

正如我在4.1成为官方稳定版本时所说：

在决定使用Tapestry之前，您应该仔细查看其开发历史。Tapestry进行了许多不兼容的升级，而旧版本的支持也没有继续。对于4.1的补丁已经不能在合理的时间内得到处理。在我看来，这对于官方稳定版本是不可接受的。

决定使用Tapestry 5意味着：

您应该成为一个committer； 您需要跟上所有新的开发，尽快放弃旧版本； 自己维护稳定版本。

4
在我看来，这似乎是一种恐吓手段；有成千上万快乐的Tapestry 5用户，只有少数贡献者。我们已经付出了很大努力，尽可能地使Tapestry 5的升级过程无痛苦。 - Howard M. Lewis Ship
1
痛苦的经历和FUD之间有所区别。 - Stephan Eggermont
0

Wicket是非常好的Web框架，是我所知道的最好的框架。我从1.3版本开始使用它，并且总是得到我想要的结果。 Wicket与Spring的集成非常出色 - 只需在您的代码中使用@SpringBean注释即可将任何Spring bean注入到您的类中。

它还与Guice良好集成（一旦您使其工作，设置有时可能会有点麻烦）。 - Laurent Grégoire
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接