关于Play（Play 2.0 介绍）

Play 2.0 介绍

2007开始，咱们一直致力于让Java开发web应用更容易。Play始于一个内部项目Zenexity，它深入影响了咱们开发web项目的方式：关注开发者生产力，遵循web架构的特色，并打破常规，使用新的打包方式－－所以称为JEE最佳实践是有道理的。

2009年，咱们决定在社区中以开源项目的方式分享成果。该举动当即获得了极积的关注与反馈，项目也愈来愈受欢迎。现在－－通过两年的活跃开发 － Play已拥有多个版本，创建了一个4000多人的活跃社区，愈来愈多的应用被部署于生产环境。

开源分享意味着会收到更多的反馈，也意味着能发现和学习更多的新用例，新特性，和在原先的设计中忽视的潜bugs。两年期间，咱们修复了某些问题，同时增长了某些新特性来支持更普遍的场景。伴随项目的成长，咱们从社区和自身的经验中学到了不少不少 －－ 正在使用Play部署更复杂更大型的项目。

同时，技术和web也在持续发展。web已经变成全部应用的中心。HTML，CSS，JavaScript的技术也在快速变革 － 几乎使得服务端框架跟不上步伐。几乎全部web架构都在迅速的向实时应用靠拢，SQL数据库再也不是数据存储的惟一选择。而在开发语言层面，咱们也目击了一些巨变，基于JVM的语言，包括Scala，正日益普及。

        这就是Play 2.0项目诞生的缘由，一个新时代的新web框架。

 构建异步应用

现在的web应用正在整合更多的并发实时数据，所以web框架必须支持完整的异步HTTP编程模型。Play最初是设计来处理经典的短暂web请求。但如今，事件模型可用于处理持久链接 －Comet, long-polling and WebSockets.

Play 2.0 一开始就基于一种假设构建，及每个请求都是潜在的长链接。但那不是所有：咱们也需具有一种建壮的方式分配和运行耗时任务。Actor-base模型处理这些高并发情形，当仁不让，而该模型的良好实如今Java和Scala语言中则是Akka－ 他来了。Play 2.0为 play 项目提供了原生的Akka支持，能够编写高度分布的系统。

关注类型安全

使用静态类型语言开发play应用的目的之一是使得编译器可以检查你的每一个代码部分。这不但使得查错更方便，也使得多人协做的大项目流程更顺利。

Play 2.0 加入了 Scala 的支持，咱们清楚的知道这会从更强大的编译器中受益 － 但这还不够。在 Play 1.x 中，模版系统是动态而基于groovy的，编译器查错能力有限。这使得模版中的错误只能在运行阶段发现。控制器验证的胶水代码也是同样。

在2.0版本，咱们推荐，让编译器在编译阶段检查你的大部分代码，这种观点。这就是咱们改用Scala作为默认模版的缘由 － 甚至对于那些以Java为主要语言的开发者。这不意味着你必须是一个Scala专家才能使用 Play 2.0 的模版，就像你没必要精通groovy也能使用 Play1.0 的模版同样。

在模版中，Scala主要用于遍历你的对象视图显示相关信息，并使用相似Java的语法。然而若是你想充分发挥Scala的能力试图编写高度抽象的模版的时候，你很快会发现，Scala，作为一门函数式语言，为什么可以完美支持模版的缘由。

这并非模版引擎的所有：路由系统也是类型安全的。Play 2.0也会彻底检查你的路由文件，验证路由声明，包括路由反向引用的部分。

所有静态编译的另外一个好处是模版和路由规则能更容易的打包和重用。你也能够在运行时得到显助的性能增益。

    原生支持 Java 和 Scala

在Play的早期版本中，咱们就开始探索Scala开发play应用的可能性。咱们一开始之外部模块的形式支持Scala，能够自由的进行试验而不影响框架自己的打包。將Scala与基于Java的框架集成并不容易。鉴于Scala和Java的兼容性，咱们天真的认为，能够迅速的实现集成，使用Scala语法代替Java语法。然而，这并非使用该语言的正确方式。Scala是一门面象对象与函数式混和的编程语言。充分发挥Scala须要重写大部分框架APIS。

咱们很快就到达到了外部模块支持Scala的瓶颈。在Play 1.x 的最初设计选择，咱们使用了大量的Java反射api和字节码加强机制，不彻底反思Play内部结构的话，会很难进展下去。同时咱们也为Scala模块开发了一些很棒的组件，如新的类例安全的模版引擎和新的SQL访问组件分支Anorm。这就是咱们决定，在Play中彻底释放Scala的能力的缘由，咱们已將该外部模块迁移到框架内部。

另外一方面，在 2.0 版本中咱们不会减小对Java的支持力度。偏偏相反，Play 2.0 的构建对Java开发者提供了一个增加经验的机会。Java开发者能够真正的沿用它们的经验。

    强大的构建系统

在Play项目伊始，咱们就选择了新的方式运行，编译与部署项目。一开始这看起来像深奥的设计，关键点是提供了一个异步的HTTP API替代标准的Servlet API，在开发阶段经过实时的编译和重载源码得到快速的反馈周期，促生了一个新的部署方式。因此，很难让Play遵循标准的JEE规范。

现在，轻容器部署在java社区中已深刻人心。这是一个让Play框架原生运行于像Heroku这类平台的机会，一种设计选择是让Play框架原生运行于Heroku这类平台中，它引入了一种模型，咱们认为这是Java应用将来部署于PaaS平台的方式。

然而，现有Java构建系统，不能灵活的部署。既然咱们要提供一个更简单直接的工具运行和部署Play应用，在Play 1.x 中，咱们提供了一系列的Python脚本处理部署任务。

同时，开发者们使用Play开发更多企业级的项目，他们须要自定义的构建流程，并与公司现有的构建系统集成，开发者为此感到有些失落了。Play 1.x 中基于Python的构建系统已力不从心。所以咱们决定为Play2.0开发一个全新的更强大的构建系统。

既然咱们须要一个先进的构建工具，须要足够灵活的支持现有的Play环境去构建Java和Scala项目，咱们选择將sbt集成进Play2.0。然而，习惯于Play旧的构建系统的用户不要被吓唬住，咱们保留了一样的 play new,run,start 模式。

Play2.0带来了一个预处理构建脚本，可以为大多数用户良好工做。另外一方面，若是你想更改应用的构建和部署方式，事实上Play项目也不过是sbt的一个标准项目，给了你按需自定义的能力。

这也意味着能与外部Maven项目更好的集成，它能將你的项目以jar文件打包发布到任何仓库中，并在开发阶段被依赖的项目实时的编译和重载，甚至是标准的Java和Scala项目。

    数据存储与模型集成

‘数据存储’再也不是‘关系数据库’的代名词，可能历来都不是。不少有趣的存储模型开始流行，它们为不一样的场景提供不一样的特性。这种状况下，像Play这样的web框架，想提早假设开发者將会使用的各式各样的数据存储机制，会变得很困难。一个通用的模型概念再也不灵光，它不可能將如些众多的存储技术抽象成统一的API。

在 Play 2.0 中，咱们想让各类数据存储驱动，ORM或其它的数据库访问层，更容易集成在一块儿。咱们只是想提供一些小工具集来解决常见的技术问题，像管理链接池。咱们也想，为了保持Play全栈式框架的优势，照顾那些没有特殊需求的用户，默认绑定了访问经典关系数据库的工具，所以，Play 2.0 提供了一些内建的关系数据库访问框架如Ebean,JPA和Anorm。