Tapestry5与Play框架比较

Question

Tapestry5与Play框架比较

playframeworktapestry

7

我知道这里有很多问题比较不同框架之间的区别。我觉得我必须再加一个。

相比Tapestry5框架，Play框架有什么优势？你推荐哪一个并为什么？

以下是我发现的相似之处:

两者都是无状态框架（我知道Play更无状态）
两者都通过实时类重载大大提高了开发人员的生产力

为什么会选择其中之一？我已经使用过两种方法来完成'Hello World'类型的应用程序，感觉两者非常相似。

- joshua

6个回答

7

我对Tapestry没有直接的经验。但是在我们使用Play的项目中，我的一个同事曾经使用过它，并且他对它非常失望。他有很多抱怨，但你可以在这里找到大部分列出的。

就个人而言，我认为Play和其他框架之间的主要比较点是：

快速周转（编辑-构建-部署周期消失）
快速开发/原型制作
支持Scala（本地支持）
用户对框架/社区的满意度（如果用户对框架/社区抱怨，那就意味着某些问题）

如果你的框架像Play一样支持所有这些功能，那么你可以深入了解细节，例如它是无状态/有状态框架等。

*Wayback机器版本，因为该帖子已从堆栈溢出中删除。

- Pere Villega

1

我想知道为什么我三个月后会收到负面评价... Tapestry的粉丝们？ :P - Pere Villega

从你提供的链接来看，原因之一是：因为Howard Lewis Ship是个骗子->这意味着“主要修订需要你完全重写你的应用程序”。确实...就像Play :D。但说真的，自v5.0以来，向后兼容性大大增强，错误报告在我看来相当不错。唯一我真正同意的事实是学习曲线。这有点像Maven，你知道有一种正确的方法，但并不总是清楚。是的，我是Tapestry的粉丝，但你的回答真的值得+1。 - Jean-Rémy Revy

7

Play框架不是基于组件的。每个页面都没有一个Java类来支持。相反，它遵循严格的MVC分离，应用程序的主体必须完全驻留在模型中。

Play旨在与Ruby on Rails或Grails非常相似，但使用Java实现。此外，可以在其内置服务器（基于JBoss Netty）上部署Play应用程序。

选择哪个主要取决于您如何处理视图层。如果您喜欢纯HTML、CSS和JavaScript，请选择Play！如果您喜欢Java组件，请选择Tapestry。

- Ludovico Fischer

4

我完全不了解Play，只看过一些5分钟的介绍，但并不喜欢它，但我有一些Tapestry 5的经验。以下是它的优点：

Tapestry是基于组件的，这是最重要的优势。如果你喜欢组件，那么组件就是必不可少的。
它非常模块化，意味着很容易将几个独立的项目组合在一起。T5是围绕一个很棒的IoC容器构建的（应该由T5团队更多地推广），因此很容易重新配置服务类（逻辑层）的默认行为。
您可以在类似于html的模板上进行构建（tapestry标记放入视图的数量取决于您的编码风格）。
当需要时，很容易在服务器端保留状态，但默认情况下，它与您提到的一样。

顺便说一句，Tapestry 5 in action书籍现已在MEAP上发布。

请注意，我对Play一无所知，只是试图回答您提出的问题。如果您想了解Tapestry的更多优点（不是与Play相比，而是框架的整体优势），请给我发消息。我很乐意写更多（特别是因为我正在说服客户从Spring转换到T5，任何练习都受欢迎;)）

问候 Michał

- Michal Gruca

这是Michal，期待您的回复。我对Tapestry非常感兴趣。在组件框架方面，我一直在使用Wicket和Guice IOC。偶尔我会看一下Tapestry。唯一的问题是文档。我不太擅长阅读维基类型的文档。我喜欢先了解整体情况，然后再使用维基/如何解决特定问题。另一方面，Wicket太麻烦了（需要维护两套几乎相同信息的文件）。所以我仍在寻找一种万能解决方案。也许T5就是那个。 - joshua

当 T5 还处于测试版时，我就在寻找我的银弹。那时候我评估了几个框架，甚至认为我已经开始使用它了，但现在我无法想象人们如何能够使用 Spring。现在我正在为一个客户使用 Spring，看到所有永远不会被创建的组件，感觉非常痛苦。此外，JSP 的丑陋让我想吐。最后，我错过了控制器和页面模板之间的集成。你需要将数据打包到模型类中才能将其发送到视图，这根本没有意义。 - Michal Gruca

1

我想说，即使对于Play和Tapestry的用户来说很明显，Tapestry比Play更传统，并更容易符合标准。我不会争论这是好事还是坏事。再次强调，离开常规路线并不总是坏事。Play有一个非常好的内置功能，因此您不需要太多额外的模块或将Play插入其他库中。 两者都拥有出色的内置功能：实时类重载，注入等等。有时候，其中一种支持比另一种更好（例如Play的REST）。它们都可以真正提高生产力。但是Tapestry比Play更接近标准。 在Play中，您不需要包含REST支持，也不需要使用Servlet引擎或插入任何构建系统。它是一个全包式的提供 :). 但是，在专业环境中需要满足标准标准时，这就变得更加困难。

最近我必须做出两次选择。

我们决定选择Play（为新客户进行绿地开发）和更有经验的自由开发人员（是的，这很重要;）
另一个 Tapestry 是因为我们真的需要符合我们客户的标准（我认为这是有充分理由的）：Maven、J2E 服务器+ JMX、使用基于 ServletFilters 的企业库，我们不想再次开发...

所以，从我的角度来看，这是这两个令人难以置信的框架之间的主要区别之一。

Matt Raible（即使有争议;）said你不应该选择框架从它们能做什么，而是关注它们不能做什么！这显然是主要的辩论！他们都可以做出伟大的作品，但在两种略微不同的方式中：）

- Jean-Rémy Revy

1

Play!框架相对于Tapestry5的好处有：

速度更快（快很多）
可以使用现有代码/模块，节省时间

Tapestry5也有第三方模块 - 但它们不会为您节省时间，而是会消耗时间。大部分都没有得到维护，您总是需要派生、理解和修改所有第三方代码，以便其能够与最新的Tapestry版本一起运行。最终，自己编写一切要容易得多。总体来说，Tapestry5的成本更高，因为您需要计算代码维护。在每次Tapestry升级时，您需要更改代码，因为方法已过时 - 不仅是您自己的代码，还有所有其他集成的第三方模块。这是一个巨大的时间杀手并且非常昂贵。

与Play!相比，您可以轻松获取Facebook/oAuth认证等内容，并且它可以在框架的下一次更新中完美运行，这是一个巨大的成本优势。

一般来说，我认为Java Web应用程序的开发、维护和托管成本最高。然而，使用Play!框架，这个计算变得更好了——尽管有时候方法不够“智能”。但是，如果时间到市场和开发成本很重要，可以选择Play!或其他技术，比如Ruby on Rails或PHP。然而，Ruby on Rails开发人员和Java开发人员一样昂贵。

- Matt

1

Play! 框架的升级并不是完全无痛的（例如 1.0 vs 1.2），因此我不会称它们为“在下一个更新中也可以正常工作”。欲了解更多详情，请参阅 http://zeroturnaround.com/blog/play-framework-unfeatures-that-irk-my-inner-geek/。 - Neeme Praks

2

我对这个前提提出异议；Tapestry在五六年前确实存在这样的问题。随着转移到新的代码库，升级变得最小程度地痛苦，并且每次发布都更容易增长。 - Howard M. Lewis Ship

2

我所见过的唯一性能对比表明，Play在与Tapestry 5.2比较时略有优势。5.3版本在重负载下要快得多。 - Howard M. Lewis Ship

Tapestry 上也有很多好用且有帮助的模块。请访问 Tapestry 的网站：http://tapestry.apache.org/community.html#Community-Modules。 - Jean-Rémy Revy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Howard M. Lewis Ship · Accepted Answer

需要注意的是，Play似乎不与标准应用程序服务器直接兼容；它不使用Servlet API，而是使用自己的Request和Reponse定义。

~~每个请求都重新编译/加载Java类，这相当严格~~（如果我记得没错的话，这是JavaOne演讲中提到的）。

它不是基于组件的，而是基于操作的框架，就像Struts或SpringMVC一样；它使用的模板比JSP更好，但缺少Tapestry的全周期方法。 Tapestry的许多强大功能来自于从简单元素构建复杂功能。

Tapestry包含了处理嵌入在JAR中的资源（图像、样式表、JavaScript库）非常复杂的技术。对于用户和开发人员来说都是透明的，只需将JAR放在类路径上，它们就会自动加载和配置。

我认为Play！有一些好的想法和非常好的名字，但它在不同的联赛中进行比赛，与Tapestry相比，它相当严格地避免任何服务器端状态... Tapestry则使用有限量的服务器端状态，并仔细管理该状态，这在很大程度上是为了支持重定向后发布语义。

在操作导向的框架中，当相同的行为跨越许多不同的页面时，你只能走得这么远。虽然我个人认为即使是单页面应用程序，也会使用Tapestry，但的确，Tapestry在开发大型应用程序和大型团队时表现得非常出色。