任何“玩”Java Web开发框架的经验？[已关闭]

我同意Jason的观点，即Play可能只是被证明比Grails更好。有四个Grails项目（之前有两个Tapestry项目和一个Wicket项目），我正在认真考虑接下来的Play。

我认为Grails很酷的一件事是“一切都是时髦的”。也就是说，您可以使用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。因此，无论如何，“一切都是时髦的”的承诺还是分崩离析了。

既然如此，我看到了Play团队的来源。

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

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

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

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

5. 我从来都不是Python的粉丝，所以当我读到Play使用Python进行构建脚本时，我感到畏缩。但我同意Grails的GANT脚本运行得相当慢。另外，我发现，虽然GANT是对XML ANT的巨大改进，但仍然很难围绕ANT概念来理解。Grails GANT脚本非常复杂。所以，我会以开放的心态进入它。

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

7. 到目前为止，我对我所阅读的Play文档印象深刻。我有大量的问题要问，但其中一半问题马上就得到了回答。

稍后，我将在深入研究时再次报告。

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

另一件让我印象深刻的事情是整体美学：教程应用程序实际上看起来不错（代码和网页设计）也许是一件小事，但这延伸到整个框架，API以及文档。