国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

Laravel 和 Spring Boot 兩個框架比較創業篇(一:開發效率)

tinna / 795人閱讀

摘要:小紅要以最低成本最快速度推出版本,投放市場,收集反饋,持續迭代。總結在技能掌握充足的情況下,個人感覺開發效率要略高于。

我個人是比較不喜歡去正兒八經的比較兩個框架的,這樣沒有意義,不過欲善其事先利其器!

技術是相通的,但是在某個特定的領域的某個階段肯定有相對最適合的一個工具!

這里比較不是從技術角度比較,而是從公司技術選型考慮的,特別是初創的互聯網創業公司。沒辦法,誰讓互聯網公司離不開軟件呢!哈哈哈。

首先是雙方選手出場介紹:

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 不念 “拉瓦”

時候不早了,有點困。今天就寫到這,明天再寫人工成本的考量。

大家晚安!謝謝

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/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...

    sf190404 評論0 收藏0
  • 后端API從入門到放棄指北

    摘要:菜鳥教程框架中文手冊入門目標使用搭建通過對數據增刪查改沒了純粹占行用的拜 后端API入門學習指北 了解一下一下概念. RESTful API標準] 所有的API都遵循[RESTful API標準]. 建議大家都簡單了解一下HTTP協議和RESTful API相關資料. 阮一峰:理解RESTful架構 阮一峰:RESTful API 設計指南 RESTful API指南 依賴注入 D...

    Airmusic 評論0 收藏0
  • 后端API從入門到放棄指北

    摘要:菜鳥教程框架中文手冊入門目標使用搭建通過對數據增刪查改沒了純粹占行用的拜 后端API入門學習指北 了解一下一下概念. RESTful API標準] 所有的API都遵循[RESTful API標準]. 建議大家都簡單了解一下HTTP協議和RESTful API相關資料. 阮一峰:理解RESTful架構 阮一峰:RESTful API 設計指南 RESTful API指南 依賴注入 D...

    Jeffrrey 評論0 收藏0

發表評論

0條評論

tinna

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<