Spring Framework与Play Framework比较

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

play framework vs spring framework

技术选型

Spring应用启动时间相对较长,且必须重新启动以应用修改。

大多开发者都喜欢使用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应用多元化需求。