1. 开发效率高 用Java但开发效率直追RoR；

2. 无状态，可拓展性好；

3. 排除bug方便代码修改后，直接刷网页如果有exception会在网页直接显示出来；

5. 源码动态编译，无需重启服务器再等几秒才能看到效果

6. 文档和例子很完善

1. 在国内还是非主流

3. play!社区比较沉稳，没有太多的市场宣传和功能承诺目前还不太会吸引不太懂技术的人戓者说要有hacker精神才会进行尝试。

这篇系列不是Play框架的Hello World由于这样嘚文章网上已经有非常多。

这篇系列会首先结合实际代码介绍Play的特点以及适用场景然后会有几篇文章介绍Play与Spring，JPA（Hibernate）的集成以及一些Play应鼡的最佳实践。 这期间会在Github上提供一个脚手架项目方便感兴趣的朋友直接动手尝试。

最后会简单分析Play的部分源码帮助大家理解黑盒子嘚内部机制。

我水平有限有错误欢迎指出。

要介绍Play之前首先理清Play的两个不同的分支。 Play 1.x 使用Java开发最新版本号是1.3.1，仅仅支持Java项目

从11年開始就进入了维护阶段，新项目一般不考虑使用Play1

Play 2.x 使用Scala和Java开发。同一时候支持Java和Scala项目 这里主要介绍最新的Play2.4 for Java。有一点须要提前说明尽管Play2主要由Scala开发，可是对于项目中的一般开发者而言 使用Play能够全然不懂Scala。详细情况后面会说明

如今的Web框架或者类库能够说是浩如烟海。近┿年来在Web开发领域，JVM阵营的占有率一直不高 数据来源()
这是国外开源项目的数据，相对来说国内Java框架的使用率会高一些而近期几年，Ruby囷Python在国内的开发群体也在不断壮大

Java框架在Web领域不那么受欢迎，主要原因在于开发速度远落后于其它的开发框架对于初创公司而言，高速开发出产品投入市场试错比花半年打磨出一款功能性能齐备的 应用更加重要而对于成熟产品，也须要高速响应频繁的需求变化这方媔动态语言又更胜一筹。所以说到Web后端框架的技术选型除非技术团队有比較深的JVM背景。 否则会倾向于选择RoRDjango这些框架。

JVM阵营在Web领域逐渐落后主要有三个原因：编译的锅技术栈的锅和语言的锅。

大家都知道Java源码须要编译之后才干执行直接结果是每次改动源码都须要重新啟动Webserver才干看到效果。

假设项目比較小类也少重新启动时间还勉强能接受。

我曾经參与的一个项目使用的是WebLogicserver。Spring容器里大概有上千个Bean重噺启动一次至少得花5分钟。还是优化后的结果工作时间至少有20%花在重新启动上了。 尽管如今有JRebel之类的热载入技术可是国内使用的相对較少。

Servlet规范在1997年出现在当时能够说是非常先进的技术。加上Tomcat的横空出世直接促成了JSP的崛起。然而时过境迁Servlet风光不再。 Web容器存在的必偠性也

原因就在于人为的将应用与容器剥离， 尽管这样的做法本意是好的可是结果就是给开发測试部署带来一系列集成的问题，如今樾来越多的项目開始使用内嵌的Jetty或Tomcat就是一个现实的样例 Servlet还带来一个问题，就是有状态的server一旦使用了Session，server就无法享受到水平扩展的长处了由此不得不採用Session复制或者粘性Session(Sticky Session)的 方案来解决问题，不管採取哪种方案都会有性能损耗而且推高了技术成本。

Servlet说究竟是Java EE家族的一员由於Sun的领导（Oracle背锅）， 从Java EE 5開始Java EE的角色已经从技术创新者转换为尾随者，这些年基本上能够说是跟着开源社区的步子在走的除了政府大单囷跨国企业，你非常难再看见它的身影了

至于语言。事实上从JDK8開始Java已经非常好用了。

只是从JDK5到JDK8十年太长。尤其是在Web

之前Java阵营受累於没有成熟的高速开发框架。Spring热衷于提供各种集成方案可是配置和使用还是相当的麻烦，直到Spring Boot的出现才有改善 只是近几年出现了一些楿当优秀的框架，如。 这篇系列要介绍的Play，通过ClassLoader在源码改动的时候动态载入类攻克了改动代码须要重新启动server的问题，全然抛弃了Servlet技術栈基于Netty实现了自己的 请求响应接口（Request/Result），基于Play的应用就是无状态的另外Play处理请求的方式是无堵塞的（Non-Blocking）。Play2在设计的时候借鉴了RoR的很哆长处 学习Play能够让你了解一些现代化框架的特点，同一时候能够为你打开异步编程世界的大门Promise已经被Scala，JavaScript等语言大量使用Actor模型也已经遍地开花。 这些你都能够直接在Play中使用或者你想保持原来的编程风格也全然没有问题。

1) 简单易上手, 没有JSP里面繁杂的内置对象和指令, 全部功能都通过方法调用完毕.
2) 主流IDE中都支持Play模板的静态类型检查, 相似JSP.
举个样例, 一般系统都会有一个固定的页面布局, 比方分出页头页尾假设用JSP戓者Velocity之类的模板。 一般都是通过sitemesh+filter或者在每一个页面include来完毕布局使用Play模板, 完毕这个功能非常easy。 首先定义一个main页面 main.scala.html：

这一部分是參数声明這里声明了三个參数:title标题, 有默认值；staticFile为html代码块, 能够传js等。content为页面内容

为什么能这样引用，由于这些页面(main,header,navigator)都会被自己主动 编译成一个方法（准确地说是一个Scala object只是这里先当做方法），所以这里相当于方法调用相同。这个main也会被编译成方法其它页面能够调用main来完毕布局。 仳如 login.scala.html

这就是一个简单的登录页面

登录页面调用main页面的方法，第一个參数不传使用默认标题第二个參数传入登录页面的js代码，第三个參數传入登录页面的html代码 这样就完毕了页面布局, 没有随处可见的include, 也没有暗箱操作的filter, 全部的一切都是方法调用, 是不是非常简单清晰？

静态类型检查就不说了, 本来Java的一大长处(Que Dian)就是类型检查所以在Java里用Freemarker或者Velocity这样的模板的做法值得商榷。

这样的风格就是REST里的URI模板

这个上面介绍过。不用重新启动server

寻常开发的时候使用run启动Play，是跑在dev模式 Play会定时扫描源码文件夹进行热更新。而且类都是訪问的时候再载入提高启动速度。 使用start启动项目就执行在prod模式Play内置dist命令。能够把全部的文件打包成一个zip解压之后直接执行bin文件夹下的可执行文件就可以启动项目。除了JDK之外无须不论什么其它外部依赖

这大大减轻了运维成本，同一时候也能够非常方便的进行持续集成（CI）

可是仅仅要你开发过流量大一点的应用, 你就会理解这点。

假设你之前开发过Java项目, 肯定写过**.properties或者管理过一大堆的xmlJava内置库对properties文件的处理是非常弱的，你不得不自己寫一些工具类去进行处理 而且properties文件还不支持更复杂的语法。

你能非常easy读取里面的配置, 而且你也能够把自己的配置写在里面

所以项目中基本不须要使用properties或者xml文件了，除了第三方库须要的

RoR框架之所以好用。主要原因之中的一个就是环绕RoR有相当丰富的插件可供选择非常多業务功能甚至都不须要开发就能实现。

Play的插件数量当然相对于RoR还是要少一些 只是你遇到的需求基本都有现成的插件能够使用。比方发邮件, 授权和验证, sitemap生成第三方登录等等。

自己写一个插件也非常简单

由于Play诞生的时候TDD已经非常火热。所以Play对測试的支持非常好

比如以下嘚几行代码就能对Controller进行測试。

Play还内置了对 Selenium WebDriver的支持能够模拟浏览器进行測试。以下是官方的样例：

5. 使用Play过程中遇到的坑

1. 首次编译速度过慢

這是Scala的锅Scala在编译过程中要， 导致编译速度相当慢在我的机器上（Core? i5-4590 CPU @

好在sbt能够增量编译， 即首次编译之后你再改动代码。编译器仅仅會编译那些它觉得须要编译的类编译几个类的时候速度非常快，基本刷新页面就能完毕

首先得说明。最适合开发Play项目的IDE是

如今IDEA最新嘚Scala插件相比之前的版本号，已经有非常大的提升 只是偶尔还是会出现误报的情况，这个问题随着新版本号插件的公布应该会慢慢解决

這可能是初次接触Play的用户遇到的最大障碍。事实上对于大多数业务开发者来说这不是问题。使用Play for Java版本号项目代码99%都是Java代码， 而Sbt相似于Maven一旦项目搭建好后不须要过多接触，仅仅要学会几个经常使用的命令就能够了比如project root(切换项目), run(启动server在dev模式)。

我们团队大部分成员之前都沒有接触过Scala和Play经过一两周的磨合期之后都能非常顺利的使用Play进行开发了。

Play的版本号号遵循不同主版本号的API变化非常大。比方Play1和Play2就是两個不同的框架 而副版本号之间API也会有一些变化，而且不一定全然向后兼容比如使用Play2.3.x的项目在升级到2.4的时候，须要依照官方提供的迁移掱冊进行代码改动 不然是执行不了的。

这对于其它背景的开发者来说可能比較easy理解可是假设是一直习惯于使用Spring MVC或Struts2的话，可能会对这点感到不适

Play2能够算是一个现代化的框架，吸收了RoR诸多长处同一时候又攻克了Java开发中的一些痛点，在国外已经被大量使用

Play和Spring MVC的定位有些楿似。可是比Spring MVC提供更丰富的功能和Web有关的项目都能够使用Play。可是假设要用好Play对团队有一定的要求。

首先你的团队应该不是墨守成规嘚团队。

大部分人都害怕变化这是不争的事实。

JDK的发展缓慢加上国内的技术氛围着实让Java开发者过了几年的舒服日子。

你假设是05年学会叻ibatis和Spring然后这十年去环游世界了，在15年你照样能轻松找到一份待遇还算能够的工作然而事情已经開始发生变化，不会学习可能会被淘汰

其次。你的团队应该重视工作效率和质量而且有时间做出改进。国内非常多团队信奉的是人海战术

以低薪聘请大量不合格的开发者來开发业务功能。 而不是注重单人的工作效率和质量非常多项目的加班和延期都源于此。这样的团队就不适合用Play非常难想象每天都要加班去应付工作的团队有时间打磨升级自己的工具和技能。

可是反过来低效率的工具和技能又拖累了自己的工作效率这是一个恶性循环。

最后团队中须要有人对Scala和Sbt有一定的了解。尽管Play有Java版本号能够使用可是假设不会Scala和Sbt，在搭建好开发环境使用一些高级功能（如Filter）的時候可能会遇到麻烦。

下篇我会介绍Play和Spring还有JPA（Hibernate）的集成毕竟Spring在大部分Java项目还是主流。有问题和建议欢迎指出