关于Play(Play 2.0 介绍)

原创
2012/03/19 01:31
阅读数 21.7W

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。
展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
4 收藏
0
分享
返回顶部
顶部