Playframework 1.4.x 与Playframework 2.5.x 选型比较

Playframework 2.5.x

优势：

  • 文档齐全，持续更新；
  • 支持更多最新的技术，更清晰的底层技术；
  • 完全异步的HTTP编程模型；
  • 通过 Comet, long-polling and WebSockets 给客户端提供持续的连接；
  • 通过 Akka 的 Actor 模型提供响应高并发的系统；
  • 使用 Akka Streams
    • Filters
    • Streaming response bodies
    • Request body parsers
    • WebSockets
    • Streaming WS client responses
  • 使用 Websocket
  • 使用 Ebean 或 JPA 和 Anorm（用于Scala）作为数据层，Java 建议用 Ebean，
  • 使用 Comet sockets
  • 使用更强大的 The Twirl template engine，即 Scala 的界面模板，
    • 模板是要编译的，编译前更早报错，报错更准确。
    • 语法简洁，只有一个“@“特殊字符，借助强大的 Scala 语言功能更强大。
    • 函数式编程的语法和表达式非常适合模板引擎。
  • 路由系统 routing system 也是编译的，帮助提早发现错误。
  • 强大而易用的自动化测试系统。
  • 采用 sbt 作为集成编译工具，可以很好地与 Maven 等传统工具结合，这样也就可以很好地和已有系统集成。
  • 有很多的实际示例代码和模组 Module 可用，如下：
  • 很多方面都有针对性的优雅解决方案，如：
    • CSRF
    • JSON 转换 Play 2 使用的是 Jackson 而不是 google 的那个 gson。
    • Database Evolutions
    • Deploy 部署 dist 命令很强大，直接打个zip包，解压后，运行 bin 目录下的 run 命令就可以启动服务了。甚至可以打成各个系统 Native 的安装包，如 *.msi (Windows), *.apk (macOS), *.rpm (Linux) 等

劣势：

  • 深入的功能，特别是 Akka 有一定的学习曲线。
  • Java 和 Scala 有界线，有两套API，不能自然转换，未来要用 Scala 则可能需要重写。

Playframework 1.4.x

优势：

  • 有之前的项目经验，熟悉度高；
  • 满足基本的项目需求，实现一般的（传统的）信息系统没有问题；
  • 可用之前的项目快速起步，包括与 Swagger 等的结合，部署脚本文件等。

劣势：

  • 动态语言的 Groovy 界面模板，非编译型语言，仅在运行时才能知道错误，不易排查错误原因，解释型运行效率低。
  • 太多黑科技，“不正规”地使用“正规”的 Java 技术，可能导致一些很难解决的Bug，包括与第三方 jar 包的兼容问题等。
  • 项目采用 python 做为编译等工作的工具，不易自定义和集成已有系统。

结论：越看越觉得应该直接开始使用 Play 2.5.x ，没什么可担心的，只会更好，不会入坑！

  • 一般的应用，Play 2.5.x 与 Play 1.4.x 上手难度相当，甚至在测试、Form表单、Model层（Ebean）等方面 Play 2.5.x 更有优势，有更多更专业且现成的解决方案。
  • 深层次的功能和配置等，更是Play2有所涉及（但需一定的学习曲线去掌握），而Play1就没有相关资料，只能借助第三方类库解决了，但跟Play1的结合又只能通过写它的Module来实现，麻烦情况可见一般。