spring data jpa明明很不錯了,為什麼現在還是這麼多人吹mybatis?

時間 2021-05-06 18:44:33

1樓:

沒有好壞區分,只是應用場景不同,國內很多服務涉及到複雜的場景,查詢語句異常複雜,這個時候使用jpa就不那麼美麗了,mybatis可以寫sql就很適合,而且,這種情況在國內還很多,所以。。。

2樓:夏天龍

吹mybatis沒有必要。

spring data jpa底層還是使用了 Hibernate 的 JPA 技術實現。

乙個專案的技術選型並不只是客觀的哪種技術先進,哪種技術好就選哪種,取決的因素很多。說到底,脫離了實際開發場景和業務場景的技術比較都是扯淡。

比如現在,我覺得mybatis配上mybatis plus挺好用

3樓:

個人覺得mybatis是一類無法和其他比較.

jpa和jooq是一類可以比較, first(10) 鐵定比沒任何資訊的derived function findFirst10ByLastname好吧.

4樓:艾迪森

其實小專案或者erp型別的業務複雜型專案用jpa快捷方便擁抱變化

大型網際網路專案用什麼orm已經不重要了,反而mybatis這種工程化的更合適一些

5樓:bin

mybatis用過但不深入,查詢不錯哈;jpa很完整,好用;jpa正常情況下可以做到在乙個事務中記憶體中的實體物件與資料庫記錄保持一致性。具體怎麼說呢,比如你先取出實體物件,然後改變一些狀態,這時候你再發起查詢,它會先把記憶體中的變化刷到資料庫;這時候你查詢得到的結果已經是更新的值,這個特性在一般條件下很受用,另外還有就是unitofwork的機制也很不錯。

不知道mybatis是否有類似的邏輯

6樓:plf1995

要知道不是每個專案都能本地啟動或者跑測試用例的,多少遠古專案,屎山專案都跑不起,甚至不能本地編譯。

這時寫查詢,用sql的方式,寫一步改一步,至少還能跑,知道自己寫的是什麼。

7樓:61nevermore

類似情況很多了,大多數人做開發在在乎個人感受,而不是去思考價值。類似的還有shiro和spring security。

一句話總結就是國內習慣是越輕量級越好,普遍不接受中間多一層複雜的玩意,多一層就是難用!

8樓:

因為不想引入額外的心智負擔。

做過專案就知道了。需求隨時會變化的,一開始設計很好的資料庫,很可能在隨後的迭代中改動的面目全非。而任何試圖遮蔽sql語句的orm,此時都會造成額外的工作量。

此時你就會想用一款「sql管理工具」而不是orm了——就是mybatis

9樓:有銘

首先,現在做技術的內捲嚴重,導致各種打著技術旗號的煽動性文章一大堆,吹mybatis的有,你以為吹jpa的就沒有嗎?

現實裡,mybatis用的確實多一些(確切的說,都是一些mybatis的變種,什麼自動模板生成之類的)。至於為什麼,我這兩個回答已經寫的很明白了

為什麼用mybatis的企業那麼多?

如何評價springboot+hibernate?

一言以蔽之: 以物件對映為核心思想的ORM,本質是為了遮蔽SQL而設計的,但是實踐中大家發現,遮蔽SQL是痴心妄想,sql的生命力強大的很。於是大家又往回走到「sqlHelper」的路徑上去了,但是純粹的sql又很繁瑣,大部分時候我們只是在做簡單OLTP,不需要處理複雜關係的OLAP,join來join去的;難道我寫個簡單的select單錶也要寫sql嗎?

有沒有什麼辦法能靈活的注入查詢條件呢,於是這個路徑上曾經有個先驅叫ruby on rail,把ActiveRecord和鏈式呼叫注入查詢條件玩到了歷史新高度。所以後來者都在在這個思路上繼續擴充套件。

10樓:3mm

因為快。

產品迭代要足夠的快才能占領市場。

試想一下:

乙個正常5天能完成初版的需求,需要在5天完成成品並且上線的情況下,你會怎麼建模?

我第一反應自然是把需要資料庫儲存的字段全部抽出來,然後按照三大正規化抽象一下,將各個表的儲存組合進乙個事務,然後通過萬能的sql進行組合出各種列表,詳情。

需求變更怎麼辦呢? 加下字段改下邏輯,改下sql。

jpa為什麼不流行?還不是因為sql太強了:-D

11樓:sterefine

個人也覺得jpa挺好用的,特別是單錶操作,但用深層次功能的確沒有mybatis簡單,jpa對開發者限制更多,要求也更高,舉幾個例子如下

關聯查詢,jpa要用specification或者其它外掛程式,比mybatis繁瑣

HQL和SQL有所區別,和xml裡面直接寫SQL不一樣,開發不願意掌握兩種SQL

jpa的事務控制更加難一些,低水平程式設計師容易寫著寫著不知怎麼了就OOM了

有一些隱藏問題不好找,可能是BUG,比如說in關鍵字,in裡面個數不同就會快取一條SQL,如果引數不同,就會快取很多,造成OOM

所以呢,不是說JPA不好用,是對使用者有更高的要求,限制也多,所以國內快速開發,還是喜歡mybatis的人更多一些。

如果用讀寫分離,我更傾向於用jpa寫主庫,用mybatis讀從庫

12樓:淡遠

國內mybatis用的比較多,其實大多小企業都是是跟風像阿里這種企業,對SQL的靈活性要求比較高。我談談自己的使用心得吧,我最開始一直用的jpa,用起來確實挺方便,完全符合物件導向程式設計的思想,封裝的比mybatis好很多,但是對比而言,mybatis卻帶來了更多的靈活性,往往體現在高併發和複雜SQL的調優上面,用的來說兩者各有所長。如果專案使用者量不大則建議使用jpa畢竟更輕鬆,如果對SQL效能和靈活性要求高的專案就可以選擇mybatis,而且國內還有mybatis-plus對mybatis進行了增強,也是很方便的!

SpringData JPA也能寫sql,為什麼還要用mybatis

codecv jpa也可以寫原生sql。mybatis也可以使用第三方增強實現根據實體自動建表更新表。mybatis也可以不寫xml用註解查詢和provider。愛用啥用啥,該用啥用啥,有什麼可爭的。我都會。 von change 可以試試spring data mybatis mini githu...

明明是他冷戰,明明是他移情別戀,明明是他要冷靜一段,為什麼我放手了,他還理直氣壯發脾氣

海賊王 因為他的脾氣比你大,當你脾氣比他大的時候他就慫了。對與錯沒有根據,但是有個道理。錯了就不該有過火的脾氣。你應該學會這點 Amanda顧霓禕 明明都放手了,明明都累了,明明都在說對方無理取鬧了你為啥還那麼在意?為啥還要氣的半死不活的,你是受虐體質?與其因為他而悶悶不樂,還不如將那點時間花在父母...

明明想做,明明知道如何去做,但是就是沒有去做,這是為什麼呢?

只是在頭腦中 紙面上對一件事進行周密的思考和去切實的執行它是有本質區別的。切實去執行需要消耗你的體力 意志力。道理很簡單,你想要得到結果就必須用付出來換取。但是相比於執行這件事,可能還是先娛樂享受一波來得更加舒服。人從本能上是不會去自找讓自己感到痛苦的事情的。但是僅僅是通過理智來戰勝人趨利避害的本能...