我刚刚偶然发现了以下新的 java web 框架：Play
http://www.playframework.org/documentation/1.0/home
拥有如此惊人的功能列表，我很惊讶我以前从未听说过它......
听起来像是 java web 开发的乐土……
有人试过吗？有什么真正的经验吗？你觉得值得研究吗？
【问题讨论】：
标签： java frameworks playframework
我同意 Jason 的观点，即 Play 可能会被证明比 Grails 更好。我有四个 Grails 项目（之前有两个 Tapestry 项目和一个 Wicket 项目），接下来我会认真考虑 Play。
我认为 Grails 的一个很酷的地方是“一切都是 Groovy”。也就是说，您使用 Groovy 编写所有内容（HTML 和 CSS 除外）——域、控制器、服务、页面模板 (GSP)、标签库、Hibernate API (GORM)、单元测试 (GUnit) 和构建脚本 (甘特）。您甚至可以在 Groovy 中编写 shell 脚本。因此，能够再次使用一种语言对应用程序的所有方面进行编码似乎是一种早就应该进行的简化——回想起用 C++ 或 Delphi 等单一语言编写桌面应用程序的日子。但是，我了解到一种尺寸并不适合所有人。
首先，对 Groovy 的 IDE 支持不是很好。 IntelliJ 做得最好，但由于 Groovy 是动态的，它只能做到这一点。重构工具不能（不能）捕获所有内容，因此您不能 100% 信任它们。这意味着您必须特别警惕单元测试。再说一次，因为 Grails 非常依赖在运行时发生的动态“魔法”，所以 Grails 中的单元测试必须依赖一个广泛的模拟层来模拟它，而这个模拟层很古怪。第三个问题是，您正在编写的许多所谓的 Groovy 代码实际上是领域特定语言 (DSL) 代码。 （长话短说，DSL 是 Groovy 的简写，它利用了在 Groovy 中和许多语法是可选的这一事实。）Grails 对各种配置、URL 映射等使用不同的 DSL，而且它是不一致的。例如，您指定 log4j 设置的方式与指定数据源的方式完全不同，也与 Groovy 所基于的纯 Java 不同。因此，无论如何，“一切都是 Groovy”的承诺落空了。
既然如此，我就知道 Play 团队的来源了。
为域、控制器、服务和 JUnit 回归常规 Java 是有意义的。强类型意味着 IDE 可以可靠地帮助进行智能感知、代码导航、重构等（因此，如果您对 Eclipse 感到满意，则无需为 IntelliJ 付费。）必须编写更详细的代码才能现在，重新获得强大的工具支持对我来说似乎很划算。走着瞧。
我喜欢我仍然可以在页面模板中使用 Groovy。不过，恐怕我最终可能会在模板中放入更多的代码。
我没有使用 JPA 的经验，但它似乎与 GORM 为我所做的非常接近，所以这很酷。
Grails 中的 Spring IOC 支持是完全透明的，而 Play 的支持似乎很少；但是，我认为 IOC 被过度使用了，我非常愿意在我真正需要的极少数情况下手动编写 Spring XML 映射。 （我的一个悬而未决的问题是我假设 JPA 具有事务支持，这就是为什么 Play 不需要像 Grails 那样需要 Spring 的原因，不是吗？）
我从来都不是 Python 的粉丝，所以当我读到 Play 使用 Python 作为其构建脚本时，我感到畏缩。但我同意 Grails 的 GANT 脚本运行速度很慢。另外，我发现，虽然 GANT 是对 XML ANT 的巨大改进，但仍然很难理解 ANT 概念。 Grails GANT 脚本非常复杂。所以，我会以开放的心态进入它。
Play“应用程序模块”模型听起来就像 Grails 的“插件”模型，所以这很酷。
到目前为止，我对 Play 文档印象深刻。我有大量的问题要问，但其中一半得到了立即回答。
稍后我会在深入研究时再次报告。
【讨论】：
我尝试过 Play，我印象深刻：它在提供比大多数框架简单得多的有用开发模型方面做得很好。最重要的是，运行时在“开发模式”下直接解析 .java 文件的能力非常值得：只需在浏览器中重新加载网页而不运行构建脚本或等待重新部署就值得很多开发速度。浏览器中显示的错误信息也很不错。
让我印象深刻的另一件事是整体美感：教程应用程序实际上看起来不错（代码和网页设计）可能是一件小事，但这延伸到整个框架、API 以及文档。
【讨论】：
在一位同事的催促下，我查看了它，按照教程进行操作，然后就上瘾了。在浏览器中获得即时反馈意味着您不必使用 IDE。我喜欢 Eclipse，但让我们面对现实吧：在添加了一些附加功能之后，它就不像一个简单的文本编辑器那么稳定了。在带有 TextMate 的 Mac 上，您甚至可以单击浏览器中的错误消息，然后 TextMate 会弹出该行的光标。
Play 中的测试也做得很好，一键运行单元测试、功能测试和基于 Selenium 的测试。
游戏令人兴奋，因为它仍然很小且不复杂。它只使用 ant 来构建并在 25 秒内完成。对精美文档的贡献是编辑 .textile 文件并在任何 play 应用中重新加载文档。
这就是我最终决定将教程翻译成使用 Scala 的方式，并在需要的地方添加对 Scala 的支持以使其尽可能好。
【讨论】：
我喜欢它，我将它用于小型项目，到目前为止它看起来非常适合这项工作。 但是，有一件我非常想念的东西被故意遗漏了：服务/DAO/模型层分离！文档清楚地表明，Play 的目标之一是避免“贫血数据模型”： http://www.playframework.org/documentation/1.0.1/model
但根据我的经验，当应用程序需要重构时，经典的 Service/DAO/Model 层分离可以节省大量的开发时间！使用 Play，您会被依赖于 Play 特定事务管理和特性的静态方法困住......
但是，很多人都对：开发速度、代码简洁性以及最终...有趣！
【讨论】：
我使用过 Grails、Tapestry 4/5 和直接的 Java/JSP/Spring/Hibernate。
我认为这是很长一段时间以来第一次朝着正确的方向发展。 Grails 是一个非常好的第一步，但 Play！看起来像是真的有腿的东西。 Scala 支持将在 1.1 中提供。如果有机会我可以在 Clojure 中编写我的控制器/域，我就被卖掉了 ;)
【讨论】：
自从 18 次小版本发布一年后没有可见的错误，我们使用 Play！ 1.2.4 在一个生产“缺席”的学校内部网应用程序中（演员：>100 名教师，>700 名学生，管理团队）。客户端是用 Adobe 的 FLEX 4.6 编写的（非常漂亮的视图）。数据以 AMF3 格式（Cinnamon 模块）发送和接收。我们为 DB 使用基于 JPA EclipseLink 和 MySql 的自己的简单 dao 层。应用程序存储在 Linux 虚拟服务器上。我是 Play 的忠实开发者，因为它的简单性和高效的方法。
【讨论】：
我喜欢 Play 的外观，但还没有尝试过。从扫描文档中脱颖而出的一件事是大量使用静态方法。从单元测试的角度来看，这总是使事情变得更加困难（我在想模拟），并且背离了典型 Java 开发中的 OO-everywhere 方法。也许这就是重点，但这只是让我不那么热情的事情......
【讨论】：
我目前在工作中使用执行大量数据处理的 play 框架构建 Web 应用程序。我必须说，游戏单独提供的速度非常重要，而且比 RoR 所能提供的速度还要快。此外，play 是一个基于 java 的框架，因此可以轻松完成多线程。接下来是当您将 Japid 和 Netty 等基于 java 的模块与 play 一起使用时获得的绝对性能。这就像可以对性能进行无休止的调整一样。我认为必须尝试。
【讨论】：
我在一个小项目中使用 Play，这似乎正是他们所说的。但是我认为框架中应该默认存在一项功能：使用多个数据源的能力（例如，使用多个数据库模式）。这是迄今为止我发现的唯一缺失的功能。
问候， 乌莲。
【讨论】：