Tapestry5 vs Play 框架答案

【问题标题】：Tapestry5 vs Play frameworkTapestry5 vs Play 框架
【发布时间】：2011-03-14 09:20:14
【问题描述】：

我知道这里有很多问题比较一个框架和另一个。我觉得我必须再添加一个。

play框架比Tapestry5框架有什么优势？你会推荐哪一个？为什么？

这是我发现的相似之处。

两者都是无状态框架（我知道 play 更无状态）
两者都通过实时类重新加载真正提高了开发人员的工作效率

为什么一个人会选择一个而不是另一个。我都用过这两种应用程序来做一个“美化你好世界”类型的应用程序，我觉得两者都非常相似。

【问题讨论】：

标签： playframework tapestry

【解决方案1】：

另请注意，Play 似乎（直接？）与标准应用服务器不兼容；它不使用 Servlet API，但它有自己的 Request 和 Reponse 定义。

~~这也是相当苛刻的，在每个请求上重新编译/重新加载 Java 类~~（如果这是 FUD，我很抱歉，这是我在 JavaOne 演讲中记得的）。

它不是基于组件的，它是一个基于动作的框架，如 Struts 或 SpringMVC；它使用的模板是对 JSP 的改进，但缺少 Tapestry 更全周期的方法。 Tapestry 的大部分功能来自于从简单的元素构建复杂的功能。

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

我想玩！有一些好主意，而且名字很好，但它在与 Tapestry 不同的联赛中打球。避免任何服务器端状态是相当严厉的......相比之下，Tapestry 使用有限数量的服务器端状态并仔细管理该状态，并且这样做主要是为了包含重定向后的语义。

到目前为止，当您在许多不同的页面上具有相同的行为时，您可以使用面向操作的框架。尽管我个人甚至会在单页应用程序上使用 Tapestry，但 Tapestry 确实在与更大的团队一起开发更大规模的应用程序时确实非常出色。

【讨论】：

感谢 HMLS。我还在等待 Tapestry5 in action Book。希望它很快就会出来。
Play 可以作为 .war 部署到 Servlet 服务器中，但这不是推荐的方式。我一点也不怀念 servlet API。
"在每个请求上重新编译/重新加载 Java 类" - 仅当它们已更改，并且仅当它在开发模式下运行时。生产模式已预编译。
我为任何 FUD 道歉。我正在根据我在您的 JavaOne 演讲中所记得的内容来工作……有点希望您能和我一起摇摆！
我从你的回答中划掉了 FUD，希望你不介意。

【解决方案2】：

我没有直接使用 Tapestry 的经验。但是我们使用 Play 的项目中的一位同事已经使用它，他真的厌倦了它。他有很多抱怨，但你可以发现其中大部分都列出了here*。

个人认为Play和其他框架的主要比较点是：

快速周转（编辑-构建-部署周期消失）
快速开发/原型设计
支持 Scala（本机）
用户使用框架/社区的幸福感（如果用户抱怨框架/社区，那就意味着什么）

如果您的框架支持所有这些以及 Play，那么您可以更深入地了解细节，例如它是否是无状态/有状态框架等。

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

【讨论】：

我想知道为什么我在 3 个月后得到了反对票... Tapestry 粉丝？ :P
从您指出的链接中：原因 1：因为 Howard Lewis Ship 是个骗子 -> 意味着“重大修订需要您完全重写您的应用程序”。确实......喜欢玩：D。不过说真的，自 v5.0 以来，向后兼容性有了很大的提高，而且在我看来，错误报告非常好。我真正同意的唯一事实是学习曲线。这有点像你知道的 Maven，有一种方法可以做得很好，但并不总是很清楚。是的，我是 Tapestry 的粉丝，但你的回答真的值得 +1。

【解决方案3】：

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

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

你选择哪一个主要取决于你如何接近视图层。如果您更喜欢纯 HTML、CSS 和 JavaScript，请使用 Play!。如果您更喜欢 Java 组件，请使用 Tapestry。

【讨论】：

【解决方案4】：

我根本不知道玩，我只看过一些5分钟的介绍，但不喜欢它，但我对Tapestry 5有一些经验。有什么优势：

Tapestry 是基于组件的，这是第一个也是最重要的优势。组件只是你不能没有的东西（如果你当然喜欢它们；））
它是非常模块化的，这意味着很容易组合几个独立的项目。 T5 是围绕出色的 IoC 容器构建的（应该由 T5 团队进一步推广），因此很容易重新配置服务类（逻辑层）的默认行为
您在 html 之类的模板之上构建（查看多少挂毯标签取决于您的编码风格）
在需要时在服务器端保持状态很容易，但是，默认情况下它就像您提到的那样。

BTW Tapestry 5 in action book 刚刚在 MEAP 上发布

再次请注意，我对游戏一无所知，只是想解决您提到的问题。如果您想要 Tapestry 的更多优势（不是过度发挥，而是框架的整体强大方面，请给我发消息。我很乐意写更多内容（尤其是在我正在说服客户从 Spring 切换到 T5 的过程中，以及欢迎在演讲之前进行任何练习；））

问候米哈乌

【讨论】：

这个 Michal 为您的回应。我对挂毯非常感兴趣。在组件框架方面，我一直在使用 wicket 和 guice ioc。偶尔我会偷看挂毯。唯一的问题是文档。我不擅长阅读 wiki 类型的文档。我喜欢先了解全局，然后使用 wiki/howTos 来解决具体问题。另一方面，Wicket 的工作量太大（维护 2 组具有几乎相同信息的文件）。所以我仍在寻找银弹。可能是 T5。
当 T5 仍处于测试阶段时，我正在寻找我的灵丹妙药。我当时评估了几个框架，甚至认为我是从它开始的，现在我无法想象人们会如何与 spring 一起生活。（编辑-所以不接受输入；））。现在我在春天为一个客户工作，看到所有这些永远不会被创建的组件是很痛苦的。 jsp的丑陋也让我想呕吐。最后但并非最不重要的一点是，我想念控制器和页面模板之间的集成。您需要做一些尴尬的事情，例如将数据打包到模型类中以将其发送到视图，这是没有意义的

【解决方案5】：

Play 的好处！框架与 Tapestry5 是：

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

Tapestry5 也有第 3 方模块 - 但它们不会为您节省时间，它们会消耗时间。它们中的大多数都没有维护，您总是需要分叉、理解和修改所有 3rd 方代码，以便它可以与最新的 Tapestry 版本一起使用。最后，自己编写所有内容会更容易。一般来说 Tapestry5 比较贵，因为你需要计算代码维护。在每次 Tapestry 升级时，您都需要更改代码，因为方法已被弃用 - 不仅在您自己的代码中，而且在您集成的第三方的所有其他模块中。这是一个很大的时间杀手，而且要花很多钱。

与玩相比！您可以在其中获取 Facebook/oAuth 身份验证之类的东西，并且它可以正常工作 - 在框架的下一次更新中也是如此，这是一个巨大的成本优势。

总的来说，我一直认为 Java webapp 的开发、维护和托管成本最高。然而，使用 Play!，计算变得更好——尽管这种方法有时不太“智能”。但是，如果考虑上市时间和开发成本，请选择 Play！或其他一些技术，例如 RubyonRails 或 PHP。然而，RubyonRails 开发人员和 Java 开发人员一样昂贵。

【讨论】：

玩！框架升级也不是完全没有痛苦的（例如 1.0 与 1.2），所以我不会称它们为“它只是有效 - 在下一次更新中也是如此”。更多详情zeroturnaround.com/blog/…
我反对这个前提； Tapestry 在五六年前就有这样的问题。随着迁移到新的代码库，升级的痛苦降到了最低限度，并且随着每个版本的发布变得越来越容易。
我见过的唯一一次正面交锋在性能方面给 Tapestry 5.2 带来了一点优势。 5.3 的速度要快很多，尤其是在重负载下。
Tapestry 上也有很好且有用的模块。看看 Tapestry 的网站：tapestry.apache.org/community.html#Community-Modules

【解决方案6】：

我还要说，即使对于 Play 和 Tapestry 用户来说，Tapestry 比 Play 更传统，更容易满足标准。我不认为这是好事还是坏事.再一次，离开人迹罕至的地方通常并不是一件坏事。 Play 有一个非常好的内置自制东西。因此，您不需要太多额外的模块或将 Play 插入其他库。

两者都具有出色的内置功能：显然令人难以置信的实时类重新加载、注入……有时一个比另一个有更好的支持（例如 REST for Play）。他们都真正提高了生产力。 但 Tapestry 比 Play 更接近标准。

您不需要在 Play 中包含 REST 支持，也不需要使用 Servlet 引擎或插入任何构建系统。这是一个全包优惠:)。但是，当您需要在专业环境中达到标准标准时，就更加困难了。

我最近不得不做出两次选择。

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

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

Matt Raible（即使有争议；））said 你不应该从可以做的事情中选择框架，而应该从他们不能做的事情中选择框架！ 这显然是这里的主要争论！两者都可以做得很好，但方式略有不同:)

【讨论】：