我同意杰森的观点，认为Play可能会比Grails更好。我有四个Grails项目（之前有两个Tapestry项目和一个Wicket项目），接下来我将认真研究Play。

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

一方面，IDE对Groovy的支持不是很好。IntelliJ做得最好，但是随着Groovy是动态的，它只能走得那么远。重构工具不能（无法）捕获所有内容，因此您不能100％相信它们。这意味着您必须特别警惕单元测试。再一次，由于Grails非常依赖于运行时发生的动态“魔术”，因此Grails中的单元测试必须依靠广泛的模拟层来进行模拟，而该模拟层是古怪的。第三个问题是，您正在编写的许多所谓的Groovy代码实际上是特定于域的语言（DSL）代码。（总而言之，DSL是Groovy的简称，它利用了Groovy的事实，并且许多语法是可选的。）Grails对不同的配置，URL映射等使用不同的DSL。这是不一致的。例如，如何指定log4j设置看起来与指定数据源的方式完全不同，也没有看上去像Groovy所基于的纯Java。因此，“一切皆有可能”的诺言反而破裂了。

既然如此，我就会知道Play团队的来历。

1. 对于域，控制器，服务和JUnits，回到常规Java是有意义的。强大的类型化意味着IDE可以可靠地帮助您进行智能感知，代码导航，重构等。（因此，如果您对Eclipse感到满意，则无需为IntelliJ付费。）必须编写更多详细的代码才能现在，获得强大的工具支持对我来说似乎是一笔好买卖。我们拭目以待。

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

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

4. Grails中的Spring IOC支持是完全透明的，而Play的支持似乎很少。但是，我认为IOC被过度使用了，我非常愿意在我真正需要的罕见情况下手动编写SpringXML映射代码。（我的一个公开问题是，我假设JPA具有事务支持，这就是为什么Play不需要像Grails那样需要Spring，是吗？）

5. 我从来都不是Python的粉丝，因此当我得知Play使用Python作为其构建脚本时，我感到非常害怕。但是我同意Grails的GANT脚本运行非常慢。另外，我发现，尽管GANT是XML ANT的巨大改进，但仍然很难将您的头围住ANT概念。Grails GANT脚本非常复杂。因此，我将以开放的心态进行研究。

6. Play的“应用程序模块”模型听起来就像Grails的“插件”模型一样，这很酷。

7. 到目前为止，我对Play文档印象深刻。我遇到了很多问题，但其中一半很快得到了回答。

我会在深入时再报告。