技术记录栈

记录点滴:java、datebase、linux、spring、javascript、nginx

2019/01/01

playframework和springframework比较

是选择Play Framework还是Spring Framework(Spring MVC)?该如何决择呢?

play framework vs spring framework

从纯技术角度

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

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

非阻塞I/O

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

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

函数式编程

Spring围绕着一堆可变对象,注释、XML配置文件和其他构建方式。导致大多数Spring MVC应用程序都是一个巨型的意大利面团(难维护、逻辑缠绕的设计)。

Play的核心是围绕函数式编程进行构建。几乎所有东西都是一个有返回值的函数,它们可以很好地利用类型系统(不仅是类型安全的类,还有类型安全的路由,模板等),这使得代码更容易推理,编写和重用应用程序的各个部分,调试问题,插入自定义行为等等。

更好的错误报告

使用Spring,将在一个巨大的日志文件中,去查看一个晦涩的、难以理解的堆栈跟踪信息。

使用Play,可以在浏览器中获得明确的错误消息,和有问题的代码片段。值得一提的是,Play可以更好地利用类型系统,因此大多数错误都可以在编译时发现,而不是运行时错误。

技术风险

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

Play是围绕异步I/O构建,而Java缺少关键的语言功能(如闭包),对于流功能(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应用程序。