“玩”java web 开发框架的任何经验？

any experience with "Play" java web development framework?

提问by opensas

I've just stumbled upon the following new java web framework: Play

我刚刚偶然发现了以下新的 Java Web 框架：Play

http://www.playframework.org/

http://www.playframework.org/

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

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

with such a stunning list of features, I'm pretty much surprised I haven't heard of it before...

拥有如此令人惊叹的功能列表，我很惊讶我以前从未听说过它......

Sounds like the java web development promised land...

听起来像java web开发的乐土……

has anybody tried it? any real experience with it? do you think it's worth studying it?

有人试过吗？有什么真正的经验吗？你觉得值得研究吗？

回答by Craig Jones

I agree with Jason that Play might just prove to be better than Grails. With four Grails projects under my belt (preceded by two Tapestry projects and one Wicket project), I'm seriously looking at Play next.

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

One of the things I thought was cool about Grails is that "everything's Groovy." That is, you use Groovy to write everything (except the HTML and the CSS) -- domains, controllers, services, page templates (GSP), tag libraries, Hibernate API (GORM), unit tests (GUnit), and build scripts (GANT). You can even write shell scripts in Groovy. So, being able to code all aspects of an app using a single language again seemed like a simplification that was long overdue -- hearkening back to the days of writing desktop apps in a single language like C++ or Delphi. However, I've learned that one size does not fit all here.

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

For one, the IDE support for Groovy isn't great. IntelliJ does the best job, but with Groovy being dynamic, it can only go so far. The refactoring tools do not (cannot) catch everything, so you can't trust them 100%. This means you have to be especially vigilant with unit testing. Here again, because Grails relies so much on dynamic "magic" that happens at runtime, the unit testing in Grails must rely on an extensive mocking layer to emulate it, and that mocking layer is quirky. A third issue is that much of the so-called Groovy code that you're writing is actually domain-specific-language (DSL) code. (To make a long story short, DSLs are short-hand Groovy, taking advantage of the fact that in Groovy and lot of the syntax is optional.) Grails uses different DSLs for various configurations, URL mapping, etc. and it is inconsistent. How you specify log4j settings, for example, looks nothing like how you specify the data sources, and neither looks like the pure Java upon which Groovy is based. So, the promise of "everything's Groovy" falls apart anyway.

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

That being the case, I see where the Play team is coming from.

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

1. Going back to regular Java for the domains, controllers, services, and JUnits makes sense. Strong typing means the IDE can reliably help with inteli-sense, code navigation, refactoring, etc. (And thus you don't need to pay for IntelliJ if you're happy with Eclipse.) Having to write more verbose code in order to gain back strong tool support seems like a good deal to me right now. We'll see.

2. I like that I still get to use Groovy in the page templates. I'm afraid I may end up putting more code in the templates than I should, though.

3. I have no experience with JPA, but it seems like it's pretty close to what GORM does for me, so that's cool.

4. The Spring IOC support in Grails is completely transparent whereas Play's support seems minimal; however, I think that IOC is way overused and I'm perfectly willing to hand code a Spring XML mapping on the rare occasion that I really need one. (One of my open questions is that I'm assuming that JPA has transaction support which is why Play doesn't need Spring for that like Grails does, no?)

5. I've never been a fan of Python, so I cringed when I read that Play uses Python for its build scripts. But I agree that Grails' GANT scripts run pretty slow. Plus I find that, while GANT is a huge improvement over XML ANT, it's still hard to wrap your head around the ANT concepts. The Grails GANT scripts are pretty convoluted. So, I'll go in to it with an open mind.

6. The Play "application module" model sounds to be just like Grails' "plugin" model, so that's cool.

7. I'm quite impressed with the Play documentation that I've read so far. I had a huge number of questions going in, but half of them were answered right off the bat.

1. 为域、控制器、服务和 JUnit 回归常规 Java 是有道理的。强类型意味着 IDE 可以可靠地帮助进行智能感知、代码导航、重构等。（因此，如果您对 Eclipse 感到满意，则无需为 IntelliJ 付费。）现在重新获得强大的工具支持对我来说似乎很划算。走着瞧。

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

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

4. Grails 中的 Spring 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 文档给我留下了深刻的印象。我提出了大量问题，但其中一半立即得到了回答。

I'll report back again later as I dive deeper in.

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

回答by Peter Hilton

I've tried Play and I'm impressed: it does a great job of delivering a useful development model that is far simpler than most frameworks'. More than anything else, the runtime's ability in 'development mode' to parse .java files directly is worth a lot: just reloading the web page in the browser without running a build script or waiting for a redeployment is worth a lot of development speed. The error messages shown in the browser are really good too.

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

Another thing that impressed me was the overall aesthetic: it is perhaps a small thing that the tutorial application actually looks good (both the code and the web page design), but this extends to the whole framework, the API as well as the documentation.

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

回答by Bart Schuller

After prodding from a colleague I looked at it, followed the tutorial, and got hooked. Getting immediate feedback right in your browser means you don't have to use an IDE. I love Eclipse, but let's face it: after you've added some extras, it's not as stable as a simple text editor. On a Mac with TextMate you can even click on the error message in your browser and TextMate pops up with the cursor on that line.

在同事的催促下，我看了它，按照教程进行操作，然后就上瘾了。在浏览器中直接获得反馈意味着您不必使用 IDE。我喜欢 Eclipse，但让我们面对现实吧：在您添加了一些额外功能之后，它不如简单的文本编辑器那么稳定。在带有 TextMate 的 Mac 上，您甚至可以单击浏览器中的错误消息，TextMate 会弹出该行的光标。

Testing in Play is also nicely done, with one button press you run unit tests, functional tests and Selenium-based tests.

Play 中的测试也做得很好，一键运行单元测试、功能测试和基于 Selenium 的测试。

Play is exciting because it's still small and uncomplicated. It uses just ant to build and does so in 25 seconds. Contributing to the beautiful documentation is a matter of editing the .textile files and reloading the docs in any play app.

游戏令人兴奋，因为它仍然很小且简单。它仅使用 ant 构建，并在 25 秒内完成。为漂亮的文档做出贡献是编辑 .textile 文件并在任何播放应用程序中重新加载文档的问题。

That's how I wound up on a quest to translate the tutorial to use Scala, adding to the Scala support where needed to get it as nice as possible.

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

回答by Dimitri De Franciscis

I like it, I'm using it for small projects and so far it looks perfect for the job. However, there's one thing I miss very much that's been left out on purpose: Service/DAO/Model layers separation! Documentation says it clearly, one of the goals of Play is to avoid the "Anemic data model": http://www.playframework.org/documentation/1.0.1/model

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

but in my experience the classical Service/DAO/Model layers separation saves tons of development time when the application needs to be refactored! With Play you're stuck with static methods that rely on Play-specific transaction management and peculiarities...

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

However, many thumbs up for: development speed, code cleanness, and in the end... fun!

然而，很多人都赞叹：开发速度、代码整洁，最后……有趣！

回答by Jason

I've used Grails, Tapestry 4/5 and straight Java/JSP/Spring/Hibernate.

我使用过 Grails、Tapestry 4/5 和 Java/JSP/Spring/Hibernate。

I think this is going in the right direction for the first time in a long time. Grails was a really good first step but Play! looks like something that could really have legs. Scala support is coming in 1.1. If there is a chance I can write my controllers/domain in Clojure, I'm sold ;)

我认为这是很长一段时间以来第一次朝着正确的方向发展。Grails 是一个非常好的第一步，但是 Play！看起来像真的可以有腿的东西。Scala 支持将在 1.1 中推出。如果有机会我可以在 Clojure 中编写我的控制器/域，我就被卖了 ;)

回答by jcstritt

Since one year and no visible bug after 18 small releases, we use Play! 1.2.4 in a production "absences" intranet application for a school (actors: >100 teachers, > 700 students, administrativ team). Client side has been written with FLEX 4.6 from Adobe (very beautiful views). Data are send and receive in AMF3 format (Cinnamon module). We use a own simple dao layer based on JPA EclipseLink and MySql for the DB. Application is stored on a Linux virtual server. I'm a very fan developer of Play for its simplicity and its very productive approach.

一年以来，在 18 个小版本之后没有明显的错误，我们使用 Play！1.2.4 某学校的生产“缺席”内联网应用程序（演员：>100 名教师，> 700 名学生，管理团队）。客户端已使用 Adob​​e 的 FLEX 4.6 编写（非常漂亮的视图）。数据以 AMF3 格式（肉桂模块）发送和接收。我们使用基于JPA EclipseLink 和MySql 的自己的简单dao 层作为数据库。应用程序存储在 Linux 虚拟服务器上。我非常喜欢 Play，因为它的简单性和非常高效的方法。

回答by Richard North

I like the look of Play, but haven't tried it. From scanning through the docs one thing that stood out was the heavy use of static methods. From a unit testing point of view this always makes things much harder (I'm thinking mocks), and is a departure from the OO-everywhere approach in typical Java development. Maybe this is the point, but it's just something that made me a little less enthused...

我喜欢 Play 的外观，但还没有尝试过。通过浏览文档，突出的一件事是大量使用静态方法。从单元测试的角度来看，这总是让事情变得更加困难（我认为是模拟），并且与典型 Java 开发中的 OO-everywhere 方法背道而驰。也许这就是重点，但这只是让我不那么热情的事情......

回答by Kiran

I currently build web applications at work using play framework which does massive data processing. I must say that the speed that play offers alone is significant and more than what RoR can provide. Besides, play is a java based framework and hence Multi-Threading can be done easily. Next is the sheer performance you get when you use java-based modules like Japid and Netty along with play.It's like an endless amount of tweaking can be done for performance. A must try in my opinion.

我目前使用 play 框架构建工作中的 Web 应用程序，该框架进行大量数据处理。我必须说，单靠游戏提供的速度非常重要，而且比 RoR 所能提供的速度还要快。此外，play 是一个基于 Java 的框架，因此可以轻松完成多线程。接下来是当您使用基于 Java 的模块（如 Japid 和 Netty）以及 play 时获得的绝对性能。这就像可以为性能进行无休止的调整。我认为必须尝试。

回答by Uilian

I'm using Play in a small project, and seems to be exactly what they've said about. But one feature I think should to be present by default in the framework: ability to work with more than one datasource (e.g. use more than one database schema). This is the only missing feature I've found until now.

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

Regards, Uilian.

问候，尤利安。