Play Framework 1.0和2.0之间的主要区别是什么？
随着最近发布的Play Framework 2.0，我想知道是否有人能从高层次的angular度总结Play Framework 1和2之间的主要区别。
我已经编译了一些（玩1.0 – >玩2.0）：
- 模板引擎：Groovy页面 – > Scala模板
- 坚持：hibernate – > Ebean
- 语言支持：Java – > Scala，Java
- dynamic编译：字节码注入 – >通过SBTdynamic编译
- 构build系统：不适用 – > SBT
- 可扩展性：模块，插件 – >子项目，插件，SBT插件
还有什么 ？ 阿卡？
这是我的清单，当然有一些重复
-
打破向后兼容性（这是从头开始重写）
-
核心编程在斯卡拉vs java（学习scala协作）
-
scala模板（但工作正在做groovy模板作为一个模块，以缓解迁移），所以你必须指定每个参数的types
-
sbt控制台而不是python脚本
-
sbt用于解决依赖而不是内置解决scheme（播放依赖关系命令）
-
模块的可用性，显然需要一些时间来迁移它们…
-
对于java，它有利于ebean代替hibernate（但你可以使用hibernate）
-
对于Scala来说，有了anorm（但你可以使用其他库）
-
更模块化，更容易挑选其他组件
-
更多的types安全 – 视图甚至path在编译时被检查
-
更好的性能
-
typeafe支持，它是types安全堆栈的一部分
-
更less的魔力，没有太多的字节码生成和类似的东西
-
更标准，（播放项目只是标准的sbt项目）
-
不同的控制器API（更详细的，恕我直言），你可以比较一个简单的播放1.x crud控制器与类似的播放2.0一个
-
Scala是一stream的公民，但是Java同样被支持（每个人都有本地API）
-
热重新编译是比较慢（它仍然在testing阶段，让我们希望他们解决它）
-
scala IDE支持并不像java那么成熟（但是它的发展很好）
-
asynchronous支持委托给阿卡
-
更好地为不同types的数据源做好准备，比如nosql dbs
有关更多信息，请参阅播放2.0页 （ 此处提供西class牙语翻译）和RC1文档
无论如何，我认为最主要的区别在于1.x版本试图在逃离j2ee的情况下构build自己的堆栈，现在它们是基于scala，akka，sbt和公司支持的新堆栈的一部分像types安全…
我觉得以下几点很重要。 有些是优点，有些是反对的。 你必须自己看看你喜欢什么版本。
-
核心是用Scala编写的，所以如果你不是一个Scala开发者，你不能自己修复一个bug。 这是一个1.2的实力。 此外，如果文件不是很好，你会丢失。 在游戏1.2中，您可以简单地查看代码。 在Eclipse中，你有一个IDE来轻松search引用。 我不确定它是否存在一个类似的Scala的IDE。 我听说日食intellij与它正常工作，但没有自己的经验。
-
2.0中的组件更松散耦合。 在游戏2.0中，你可以轻松地select你喜欢的模板引擎或持久层。 在1.2中，selectJPA之外的东西更难以坚持。
-
Scala现在是一stream的公民，所以如果你想用Scala或Java编写你的应用程序，你可以自由select。
-
其他框架的依赖性更高。 例如，他们现在需要Scala和Akka。 两者都很好，但很复杂。 所以如果这些框架中有一个出现错误，你可能会遇到很大的麻烦。 在播放1.2我只看到Hibernate的这种风险。
-
“一切”现在是安全的，可以由编译器检查。
-
将Python改为SBT意味着在开发机器上需要更多的内存。 我的意思是Scala编译器至less需要512 MB RAM。 这可能是连续构build服务器上的问题。
当然Codemwnci提到的很多小细节。
你的名单是一个非常好的开始。 我的列表看起来很像一些额外的东西。
- 模板已经从Groovy转移到Scala。
- 斯卡拉成为一stream的公民，而不是一个可选的插件
- 更加注重types安全，特别是在模板中
- Python到SBT
- hibernate到Ebean
- Akka来补充Play 1.x中的asynchronousfunction，而不是Akka作为模块
- 核心（而不是scala插件）
- 由于较less的dynamic元素和更多的编译，在生产中的性能改进
- 集成到TypeSafe堆栈中
我们的名单之间有重复，如你所料。 另外要注意的是，这张名单是截至2011年11月，而玩2仍在testing版。
这里有一些非常好的答案，我只是想补充一些小的观点，并提供随时间变得更加清晰的细节。
In-Browser-Reporting：在浏览器中使用Javascript（使用google的闭包编译器）和CSS文件播放2个错误报告，而不仅仅是Java / Scala文件。 这真的很酷。
部署为WAR： Play 2 仍不能正式支持部署或导出为WAR。 存在一个应该提供这种支持的插件 ，但在testing中存在一些已知问题。 如果没有Servlets 3.1容器，对所有Play 2function的全面支持是不可能的，这个容器至less需要半年，可能更多。
插件：现在，还有更多的游戏1，如果你依赖于一些插件，确保它也存在玩2。
IDE支持： IntelliJ 12应该带有对播放2的内置支持。你已经可以获得EAP了（我用完了超链接，所以你不得不谷歌）。
主观观点：我觉得Play 2为了支持更高级的function和更完整的types安全而牺牲了一些简单性。 我并不是说Play 2很难或者不直观，只比Play 1less。
Play 1是网页开发者的网页开发者的网页框架。 Play 2是Web开发人员为Web开发人员提供的前瞻性Web框架。
所以说，重点略有转移，易用性不再是主要目标，而是两个主要目标之一。 这当然只有我的意见，我知道的很less。
您可以在以下博客文章中find有关该主题的其他内容： http : //blog.awfbeat.com/post/22314115684/impressions-of-play-framework-1-2-4-vs-2-0
从这篇文章总结：
- 资产pipe道直接使用Google Closure编译器，CoffeScript和LESS
- 一切都被编译，甚至路线文件
- 低运行的应用程序的内存足迹
- 使用Iteratee / Enumerator进行asynchronous/反应式编程
- 正如你所提到的，斯卡拉，阿卡，…
