Spring Framework与Play Framework比较

Play Framework和Spring Boot都是快速构建轻量级应用的选择,它们在构建应用时都各自有哪些优势和瓶颈呢,一起做个简单的对比。

play framework vs spring framework

技术选型

Spring启动需要很长时间,并且必须重新启动(对于大型应用程序可能需要几分钟)。大多开发者都喜欢在其上构建自已的框架,一方面说明其灵活性,一方面表明其内置功能匮乏(Spring Boot有所改观)。

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

非阻塞I/O

Spring Boot默认是阻塞I/O,这意味着无论何时进行I/O(进行远程服务调用,处理客户端请求等),它都会占用一个线程。

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

函数式编程

Spring框架围绕着一堆可变对象,注释、XML配置文件等建方式。导致大多数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平台的一部分,Spring真正价值在于多元化的生态系统,这个生态下的项目相互融合,可以完成诸多需求。

在这种情况下,Spring平台开始越来越闪耀,而Play框架开始显现其极限,并导致开发者们重新发明轮子。一言以蔽之,Play框架更适合典型的Web应用程序,Spring平台更适合具有复杂需求的大型Web应用程序。