资讯专栏INFORMATION COLUMN

Laravel 和 Spring Boot 两个框架比较创业篇(一:开发效率)

tinna / 771人阅读

摘要:小红要以最低成本最快速度推出版本,投放市场,收集反馈,持续迭代。总结在技能掌握充足的情况下,个人感觉开发效率要略高于。

我个人是比较不喜欢去正儿八经的比较两个框架的,这样没有意义,不过欲善其事先利其器!

技术是相通的,但是在某个特定的领域的某个阶段肯定有相对最适合的一个工具!

这里比较不是从技术角度比较,而是从公司技术选型考虑的,特别是初创的互联网创业公司。没办法,谁让互联网公司离不开软件呢!哈哈哈。

首先是双方选手出场介绍:

Laravel


Laravel框架号称是Web艺术家的框架,富有生产力,代表了最优雅最流行的PHP框架,经过一段时间的使用,也上了一个项目,感觉特点如下:

比较规范(PHP的框架中),适合团队分工协作

开发速度快(社区生态和脚手架加持)

部署方便(PHP的部署就那样吧,Git一套推拉下来就搞定了)

功能模块比较全面

架构较复杂(在PHP框架中,O(∩_∩)O哈哈~)

全栈,前后端一个IDE搞定

其他文中再说

Spring Boot


Spring Boot准确来说并不是一个完整的框架,而是为了使 Spring 全家桶更方便使用、更亲民而产生的一个整合框架。所以Spring Boot 的背后是 Spring 近乎无敌的生态和解决方案。
先简单说一下特点吧:

背靠 Java 这个老家伙,还有 Spring 这个J2EE 的标准背书,生态非常强大

开发速度快(在Java系列中。。。),约定大于配置

基于JVM,执行效率有保障

需要掌握Spring的那一套,对于本身不是 J2EE 的童鞋学习成本有点高

有Cloud 加持,微服务在召唤

智能到令人发指的Spring Data JPA

其他稍后文中再说

好啦,介绍完选手,就开始来分析一下该用哪个啦,这里我们设定一个情境:

假设 小红 是一位有一个自认为价值 20亿 的Idea,并且打算付诸实践的小BOSS(即将成为),稍懂软件架构和开发技术,没错,是很菜的那种(如果很厉害那随便怎么用框架了,没所谓),且启动资金只有 30万。

我也不想假设的这么惨的,现实中这种情况很多,那我们就以这种情景展开分析。小红要以最低成本、最快速度推出 1.0 版本,投放市场,收集反馈,持续迭代。这是一个系统工程,讲其他因素剔除,只考虑技术问题,可以总结成以下几点:

成本(开发效率和人工成本)

响应(迭代和部署效率)

安全(稳定性和 BUG解决速度)

协作(团队协作和扩展性)

1.开发效率

开发这个过程,我们将它定义为需求和原型都已经确定,并且已经简单建模完毕,嗯,就是猿们到岗后拿着需求文档打开电脑(Windows)的时候开始,到 1.0 版本发布这段时间,是谁跑得快!O(∩_∩)O哈哈~

首先是 Laravel 框架,步骤是这样的:

配置本地环境:包括PHP-CLI、Vagrant 、VirtualBox、HomeStead Box、Composer、nodejs(Mix要用到)、Python、Virtual Studio、Node-gyp(Node-Sass要用到)、PHPStorm、Git,一切就绪后composer create-project laravel/laravel xxx

开发:定义migration、model,然后transformer和repository,再写service和passport啥的,再写controller,view视图,然后完善 Event、Notification、推送啥的,期间伴随着单元测试

部署:Git push、Git Clone 、Pull,env整一个,上线

对 Laravel 的开发流程熟悉的人呢,开发速度是很快的。

我们再来看看Spring Boot:

业务不复杂就不要折腾微服务啦,不要像某人一样明明只有一台机器,硬是要开几十个端口,然后跑几十个Spring Boot的小服务,还用Cloud全家桶串起来了。我竟无言以对

单体应用撸起来,步骤如下:

配置开发环境:IntelliJ IDEA下一个、JDK装一个、其他要用到的Redis啥的装上,分分钟就搞定可以开撸了。

开发:定义JAP Entity,Repository、Service,配置Spring Security(包括Oauth2),定义Validation,开撸Controller、异常处理,视图层啥的,单元测试也少不了

部署:打出Jar包,扔到服务器上执行吧,nginx映射一下,搞定

我个人觉得Spring Boot的开发效率要比 Laravel 框架高些!

为什么呢? 因为如果对 Spring 的机制熟悉,也了解 Security、JPA、Thymeleaf模板、RabbitMQ 等等功能模块的使用,Spring Boot 的封装是比 Laravel 要好的,但前提是对Spring 那一套熟悉,不然从何入手都弄不清楚。

Spring 有些组件是非常复杂的,例如 Spring Security

Laravel 框架借鉴了很多 Java Spring 的思想,比如容器,依赖注入、切面,这方面明显 Spring Boot 是正宗,注解啥的6得飞起!

Java 语言非常严谨,在开发过程中的体验比较好,至少像我这样天马行空的猿,还非得要 Java 这个老头来管着,不然分分钟要跑偏。

回到开发效率这个问题上,如果对两个框架都比较熟悉的情况下,Spring Boot 是开发比较快的,但 Laravel在某些方面是完胜Spring Boot,如下:

Laravel 框架的 ORM 构建需要经历两个步骤,migration 和 model ,而且改动 migration 需要调整 model,无法向 JPA 一样Entity 即数据库结构;

Laravel 框架需要手动实现一些注入绑定,通常是$app->bind,尽管这不消耗多少时间,但是比起Spring强大的注解还是慢不少,而且主流IDE对 Spring 的 Bean 提供了导航查看功能,牛逼哄哄啊;

如果要做网页渲染,Laravel的动态脚本语言特性加上Blade模板基本是秒杀Spring Boot 的;

要让层次更分明一些的话,Laravel 需要手动实现Repository 模式,反正我是受不了Model 直接定义业务逻辑的,放在Controller里也受不了,不但难看,还不好扩展;

在授权这方面,Laravel 自带的和Spring Security 都很强大,可以说是开箱即用,打平;

Laravel框架开发反馈调试方面是完胜Spring Boot的,这方面可以说所有非编译型的语言都很爽!尽管Spring Boot 也有DevTool,但是架不住 PHP 根本就不需要重新启动呀。

Laravel框架的代码提示远远比不上Spring Boot,而且还需要第三方包Ide-Helper的加持,不然代码追踪都不行,可是就算用了第三方包还是看不了 容器内长啥样啊;

像 Laravel 这样靠面向对象体现优雅的框架,却遇到了PHP 这门面向对象不太完全的语言,以致于在 Java 体系内很容易实现的一个功能,到了PHP体系却无能为力;

Route 路由这方面 Laravel 非常强大,而且直观,比Spring Boot 灵活,所以定义路由的时候效率完爆Spring Boot;

异常处理两者都非常方便,提供了统一处理的方式,难分伯仲;

Api Json数据定制这方面,Laravel 比 Spring Boot 要强大,这是因为PHP的数组操作非常灵活,对于 Java 来说需要定义工具类和实体类来专门处理;

i18n国际化,Laravel 比Spring Boot 方便;

前端资源处理,就这个功能本身来说,Laravel的Mix配合Blade模板完爆Spring Boot,但是话说回来,只要不是全栈,这不算什么优势。设想一下如果是前端做好页面,拿到后端套模板,那Thymeleaf 完爆 Blade,因为Thymeleaf 可以保留预览数据,渲染实际数据,Blade 做不到这一点。

总结:在技能掌握充足的情况下,个人感觉 Spring Boot 开发效率要略高于Laravel。个人掌握情况不一样,请勿喷,可以参考文中的几个维度,自己思考一下。

最后想提一下,顺便求证:

Laravel 不念 “拉瓦” 
Laravel 不念 “拉瓦”
Laravel 不念 “拉瓦”

时候不早了,有点困。今天就写到这,明天再写人工成本的考量。

大家晚安!谢谢

文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/30942.html

相关文章

  • Laravel Spring Boot 两个框架比较创业开发效率

    摘要:小红要以最低成本最快速度推出版本,投放市场,收集反馈,持续迭代。总结在技能掌握充足的情况下,个人感觉开发效率要略高于。 我个人是比较不喜欢去正儿八经的比较两个框架的,这样没有意义,不过欲善其事先利其器! 技术是相通的,但是在某个特定的领域的某个阶段肯定有相对最适合的一个工具! 这里比较不是从技术角度比较,而是从公司技术选型考虑的,特别是初创的互联网创业公司。没办法,谁让互联网公司离不开...

    zoomdong 评论0 收藏0
  • 后端API从入门到放弃指北

    摘要:菜鸟教程框架中文手册入门目标使用搭建通过对数据增删查改没了纯粹占行用的拜 后端API入门学习指北 了解一下一下概念. RESTful API标准] 所有的API都遵循[RESTful API标准]. 建议大家都简单了解一下HTTP协议和RESTful API相关资料. 阮一峰:理解RESTful架构 阮一峰:RESTful API 设计指南 RESTful API指南 依赖注入 D...

    Jeffrrey 评论0 收藏0
  • 后端API从入门到放弃指北

    摘要:菜鸟教程框架中文手册入门目标使用搭建通过对数据增删查改没了纯粹占行用的拜 后端API入门学习指北 了解一下一下概念. RESTful API标准] 所有的API都遵循[RESTful API标准]. 建议大家都简单了解一下HTTP协议和RESTful API相关资料. 阮一峰:理解RESTful架构 阮一峰:RESTful API 设计指南 RESTful API指南 依赖注入 D...

    sf190404 评论0 收藏0
  • 后端API从入门到放弃指北

    摘要:菜鸟教程框架中文手册入门目标使用搭建通过对数据增删查改没了纯粹占行用的拜 后端API入门学习指北 了解一下一下概念. RESTful API标准] 所有的API都遵循[RESTful API标准]. 建议大家都简单了解一下HTTP协议和RESTful API相关资料. 阮一峰:理解RESTful架构 阮一峰:RESTful API 设计指南 RESTful API指南 依赖注入 D...

    Airmusic 评论0 收藏0

发表评论

0条评论

最新活动
阅读需要支付1元查看
<