Spring Framework与Play Framework比较

Play Framework和Spring Boot都是轻量级应用的快速构建方案,该如何做技术选型呢?

play framework vs spring framework

技术选型

Spring启动时间相对较长,且必须重新启动以应用修改。大多开发者都喜欢在其上构建自已的框架,一方面证明其灵活性,一方面表明其内置功能匮乏。

Play支持热加载,修改代码并应用新功能是件容易的事(以秒为单位)。

非阻塞I/O

Spring Boot默认为阻塞I/O,Play Framework完全非阻塞I/O,在面向服务的架构中表现良好(微服务架构),支持Web socket、流媒体等,没有线程池和地狱式回调。

函数式编程

Spring框架围绕着一堆可变对象,注释、配置文件进行构建。大多数Spring MVC应用程序都像一个巨型的意大利面团。

Play框架的核心围绕函数式编程进行构建,也能很好地利用类型系统,使得代码更容易理解。

友好的错误报告

Spring对日志没有相应的解决方案,排查问题时,需在一个巨大的日志文件中,查找晦涩的堆栈信息。

Play Framework能在浏览器中获得明确的错误消息,以及有问题的代码片段。Play框架可以更好地利用类型系统,大多数错误都能在编译时发现。

技术风险

Play 2完全重写了Play 1,意味着Play社区并不像其他Java框架那样坚实,支持Play 2的插件也不会太多。未经大量实战的代码都有一个通病,太多隐藏的bug未被清除,最佳实践尚未明确定义。

Play是围绕异步I/O构建,Java缺少关键的语言功能(如:闭包,java8目前可以做到),而流功能(iteratees,enumeratees)又让开发者根本不能真正使用Java。Java现在有功能库都是同步/阻塞的,需借助Netty等异步/非阻塞功能库。

习惯了围绕HttpServletRequest,HttpServletResponse对象编程的开发者,使用Play框架会有一些蹩脚,Play框架脱离了servlet规范。

Play框架构建系统SBT,功能强大、灵活,并支持Play的一些最佳功能(热加载,交互式控制台,调试构建、共享代码及运行时能力),但SBT编码方式对于Scala专家而言都很难理解,更不用说Java开发了。

对于大多数开发者而言,这并不是什么大问题,他们只是用来构建系统,添加一两个依赖(这在Play中非常容易)。但是,如果将Play构建集成到基础架构中,对于这部分功能的开发者而言,学习曲线将会非常陡峭。

商业考量

如果制作一个简单的网站,Play Frameworky比较方便。Spring MVC扎根于Spring生态,在这个多元化的生态圈中,各个项目能够完美融合。

Play框架轻便灵活,Spring生态未来可期。Play框架适合典型的Web应用,Spring更能迎合大型Web应用的多元化需求。