有没有“Play”java web开发框架的经验？

Question

我刚刚偶然发现了以下新的java网页框架：播放

http://www.playframework.org/

http://www.playframework.org/documentation/1.0/home

有如此令人惊叹的功能列表，我很惊讶我之前没有听说过......

听起来像java web开发承诺的土地......

有人试过吗？有任何实际经验吗？你觉得值得研究吗？

Answer 1

我同意Jason的观点，认为Play可能比Grails更好。我有四个Grails项目（之前有两个Tapestry项目和一个Wicket项目），我很认真地看着Play。

我认为Grails的一个很酷的事情是“一切都是Groovy”。也就是说，您使用Groovy编写所有内容（HTML和CSS除外） - 域，控制器，服务，页面模板（GSP），标记库，Hibernate API（GORM），单元测试（GUnit）和构建脚本（ GANT）。您甚至可以在Groovy中编写shell脚本。因此，能够再次使用单一语言对应用程序的所有方面进行编码似乎是一个早就应该进行的简化 - 回到用C ++或Delphi这样的单一语言编写桌面应用程序的日子。但是，我已经了解到一种尺寸并不适合这里。

首先，IDE对Groovy的支持并不是很好。 IntelliJ做得最好，但是Groovy是动态的，它只能走得那么远。重构工具不会（不能）捕获所有内容，因此您无法100％信任它们。这意味着您必须特别警惕单元测试。在这里，由于Grails非常依赖于在运行时发生的动态“魔法”，Grails中的单元测试必须依赖于广泛的模拟层来模拟它，并且该模拟层很古怪。第三个问题是，您所编写的大部分所谓的Groovy代码实际上是特定于域的语言（DSL）代码。 （长话短说，DSL是简洁的Groovy，利用Groovy中的许多语法可选的事实。）Grails使用不同的DSL进行各种配置，URL映射等，并且它是不一致的。例如，如何指定log4j设置，看起来与指定数据源的方式完全不同，并且看起来都不像Groovy所基于的纯Java。所以，“一切都是Groovy”的承诺无论如何都会崩溃。

在这种情况下，我看到了Play团队的来源。

1. 回到常规Java领域，控制器，服务和JUnit是有道理的。强类型意味着IDE可以可靠地帮助进行内部感知，代码导航，重构等。（因此，如果您对Eclipse感到满意，则无需为IntelliJ付费。）必须编写更详细的代码才能获得强大的工具支持对我来说似乎是一个很好的交易。走着瞧。

2. 我喜欢我仍然可以在页面模板中使用Groovy。我担心我最终可能会在模板中放入比我应该更多的代码。

3. 我没有使用JPA的经验，但它似乎与GORM为我做的非常接近，所以这很酷。

4. Grails的Spring IOC支持是完全透明的，而Play的支持似乎很少;但是，我认为IOC过度使用了，我非常愿意在极少数情况下手动编写Spring XML映射代码。 （我的一个开放性问题是，我假设JPA有交易支持，这就是为什么Play不需要Spring，就像Grails那样，不是吗？）

5. 我从未成为Python的粉丝，所以当我读到Play使用Python作为构建脚本时，我感到很沮丧。但我同意Grails的GANT脚本运行得很慢。另外我发现虽然GANT是对XML ANT的巨大改进，但仍然很难围绕ANT概念。 Grails GANT脚本非常令人费解。所以，我会以开放的心态进入它。

6. 播放“应用程序模块”模型听起来就像Grails的“插件”模型，所以很酷。

7. 到目前为止，我对Play文档印象深刻。我收到了大量的问题，但其中有一半是立即回答的。

稍后我会再深入报道。

Answer 2

我尝试过Play，我印象深刻：它提供了一个比大多数框架简单得多的有用开发模型。最重要的是，运行时在“开发模式”中直接解析.java文件的能力非常值得：只需在浏览器中重新加载网页而不运行构建脚本或等待重新部署，就值得花费大量的开发速度。浏览器中显示的错误消息也非常好。

给我留下深刻印象的另一件事是整体审美：教程应用程序实际上看起来很好（代码和网页设计）可能是一件小事，但这扩展到整个框架，API以及文档。

Answer 3

在一位同事的催促下，我看着它，按照教程，迷上了。立即在浏览器中获得反馈意味着您不必使用IDE。我喜欢Eclipse，但让我们面对它：在你添加了一些额外内容后，它不如简单的文本编辑器稳定。在使用TextMate的Mac上，您甚至可以在浏览器中单击错误消息，并在该行上弹出TextMate。

Play中的测试也很顺利，只需按一下按钮就可以运行单元测试，功能测试和基于Selenium的测试。

游戏很令人兴奋，因为它仍然很小而且不复杂。它只使用ant构建，并在25秒内完成。贡献美丽的文档是一个编辑.textile文件和重新加载任何播放应用程序中的文档的问题。

这就是我在寻求翻译教程以使用Scala的过程中，在需要的地方添加Scala支持以尽可能地使用Scala。

Answer 4

我喜欢它，我将它用于小型项目，到目前为止，它看起来非常适合这项工作。 但是，有一件事我非常想念那些故意遗漏的东西：服务/ DAO /模型层分离！文档明确指出，Play的目标之一是避免“贫血数据模型”： http://www.playframework.org/documentation/1.0.1/model

但根据我的经验，当应用程序需要重构时，经典的Service / DAO / Model层分离可以节省大量的开发时间！使用Play，你会遇到依赖Play特定事务管理和特性的静态方法......

然而，许多赞许：开发速度，代码清洁，最后......好玩！

Answer 5

我使用过Grails，Tapestry 4/5和直接Java / JSP / Spring / Hibernate。

我认为这是长期以来第一次朝着正确的方向发展。 Grails是一个非常好的第一步，但玩！看起来像是真的有腿的东西。 Scala支持即将发布1.1。如果有机会我可以在Clojure中编写我的控制器/域名，我就卖掉了;）

Answer 6

由于一年而且在18个小版本之后没有可见的错误，我们使用Play！ 1.2.4在学校的生产“缺勤”内联网申请中（参与者：> 100名教师，> 700名学生，管理团队）。客户端使用Adobe的FLEX 4.6编写（非常漂亮的视图）。数据以AMF3格式发送和接收（Cinnamon模块）。我们使用基于JPA EclipseLink的自己的简单dao层和DB的MySql。应用程序存储在Linux虚拟服务器上。我是Play的粉丝开发者，因为它的简单性和高效的方法。

Answer 7

我喜欢Play的外观，但还没试过。从扫描文档中可以看出，一个突出的问题是静态方法的大量使用。从单元测试的角度来看，这总是让事情变得更加困难（我在考虑模拟），并且与典型的Java开发中的OO无处不在的方法背道而驰。也许这就是重点，但这只是让我不那么热情的事情......

Answer 8

我目前使用播放框架在工作中构建Web应用程序，该框架执行海量数据处理。我必须说，单独提供的速度是显着的，而且比RoR所能提供的速度更快。此外，play是一个基于java的框架，因此可以轻松完成多线程。接下来是使用像Japid和Netty这样的基于Java的模块以及播放时获得的绝对性能。这就像可以为性能做无穷无尽的调整。我必须尝试一下。

Answer 9

我在一个小项目中使用Play，似乎正是他们所说的。但我认为应该在框架中默认存在一个功能：使用多个数据源的能力（例如，使用多个数据库模式）。这是我迄今为止唯一缺少的功能。

此致 Uilian。