给Java开发人员的Play Framework(2.4)介绍 Part1：Play的优缺点以及适用场景

1. 关于这篇系列

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

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

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

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

2. Play介绍

Play Framework是一个开源的Web框架。背后商业公司是Typesafe。

要介绍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。详细情况后面会说明。

3. 为什么要了解Play

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

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

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的出现才有改善。只是近几年出现了一些相当优秀的框架，如Dropwizard，Play。Vert.x。这篇系列要介绍的Play，通过ClassLoader在源码改动的时候动态载入类，攻克了改动代码须要重新启动server的问题，全然抛弃了Servlet技术栈，基于Netty实现了自己的请求响应接口（Request/Result），基于Play的应用就是无状态的，另外Play处理请求的方式是无堵塞的（Non-Blocking）。Play2在设计的时候借鉴了RoR的很多长处。学习Play能够让你了解一些现代化框架的特点，同一时候能够为你打开异步编程世界的大门。Promise已经被Scala，JavaScript等语言大量使用，Actor模型也已经遍地开花。这些你都能够直接在Play中使用。或者你想保持原来的编程风格也全然没有问题。

4. Play的特性

1. Play2的模板引擎

Play2的模板是非常强大而且easy上手的. 相对于Java领域其它模板引擎(Freemarker, Velocity, JSP, Groovy, etc), 主要有三个特点.
1) 简单易上手, 没有JSP里面繁杂的内置对象和指令, 全部功能都通过方法调用完毕.
2) 主流IDE中都支持Play模板的静态类型检查, 相似JSP.
3) 支持反向路由.
举个样例, 一般系统都会有一个固定的页面布局, 比方分出页头页尾。假设用JSP或者Velocity之类的模板。一般都是通过sitemesh+filter或者在每一个页面include来完毕布局。使用Play模板, 完毕这个功能非常easy。首先定义一个main页面 main.scala.html：

@(title: String = "默认标题")(staticFile: Html = Html(""))(content: Html)

<!DOCTYPE html>

<html lang="zh-cmn-Hans">

<head>

    <meta charset="utf-8" />

    <title>@title</title>

</head>

<body>

@header()  <-- 页头 -->

@navigator() <!-- 导航 -->

@content

<script src="@routes.Assets.versioned("js/jquery-1.11.2.min.js")"></script>

@staticFile

1	`@(title: String = "默认标题")(staticFile: Html = Html(""))(content: Html)`

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

@header()  <-- 页头 -->

@navigator() <!-- 导航 -->

这一部分是引用同文件夹下的另外两个页面：header.scala.html和navigator.scala.html。

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

@main() {

    <script type="text/javascript">

        FG.user.login();

    </script>

} {

    <div class="login width1200">

    <!-- login -->

    </div>

}

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

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

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

反向路由的意思是, 在Play中, 全部的Controller url都配置在一个routes文件里, 比如

1	`GET /register @controllers.user.LoginController.registerPage`

之后不管是在Controller里还是模板中, 都不用硬编码url。而是使用routes文件。比如在Controller中使用redirect(routes.LoginController.registerPage())就能实现重定向。

而在模板中使用 <a href="@controllers.routes.LoginController.registerPage()">来指向链接。

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

2. 热部署

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

3. 内置dev/prod环境，内置部署脚本

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

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

4. 使用Play开发的Server大部分能做到Stateless

这个之前也说过。Play抛弃了Servlet/JSP里Session等概念, 内置没有提供方法将对象与server实例进行绑定(你要使用HashMap存的话Play也没办法)。推荐的做法是使用外部缓存, 比方Redis, Memcached等。可能有人会觉得没有Session是Play的一个缺点（Play里的Session和Servlet Session不是一回事）, 可是仅仅要你开发过流量大一点的应用, 你就会理解这点。

5. 好用的配置库

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

Play使用Typesafe Config库，配置文件使用HOCON格式，默认配置文件为application.conf。

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

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

6. Play插件

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

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

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

7. 优秀的測试支持

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

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

Http.RequestBuilder request = new Http.RequestBuilder().method(POST).uri(routes.LoginController.requestPhoneCode(phone).url());

Result result = route(request);

assertThat(result.status(), is(OK));

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

public class BrowserFunctionalTest extends WithBrowser {

    @Test

    public void runInBrowser() {

        browser.goTo("/");

        assertNotNull(browser.$("title").getText());

    }

}

8. 优秀的REST支持

Play2从诞生起就能非常easy的支持RESTful风格的架构（由于Play2在设计的时候REST就已经大行其道），在Play2中实现RESTful API的演示样例能够參考Stackoverflow上的这个回答

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

1. 首次编译速度过慢

这是Scala的锅。Scala在编译过程中要经历至少30个步骤，导致编译速度相当慢。在我的机器上（Core™ i5-4590 CPU @ 3.30GHz，RAM 8GB）。编译100多个Scala类大约须要1到2分钟。

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

2. IDE的Scala插件偶尔会误报错误

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

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

3. Scala和Sbt的学习成本较高

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

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

4. Play的API变化速度比較快

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

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

6.总结

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

參见数据来源(http://www.infoq.com/research/jvm-web-frameworks)

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项目还是主流。有问题和建议欢迎指出。

本文借鉴：http://skaka.me/blog/2015/07/27/play1/