關於Jpa和Mybatis的一些見解

如今網絡上充斥着Jpa和Mybatis的一些對比。其實狹義上來講是hibernate和mybatis之間的比較。mysql

例如:爲何感受國內比較流行的 mybatis 在國外好像沒人用的樣子?程序員

下面是一些截圖spring

我不是一個喜歡評論的人,但此次我忍不住了。sql

  • hibernate 歷史悠久並不表明過期,mybatis 這種方式就是將來嗎?確定不是。數據庫就是用來存數據的,聯表查詢一大堆只能說明數據結構設計是有問題的,只是不肯認可或者內心沒底而已,居然還有人爲了排序篩選數據,把複雜的運算放到關係型數據庫去作,咋不上天呀,你這是叫格力的倉管大爺去替你拿材料,順便讓他根據各類因子計算新型壓縮機的功率損耗。數據分析就不該該讓關係型數據庫作,這叫各司其職。
  • 這條語句的邏輯頗有意思: UPDATE items SET price = 11 WHERE id = 1111,難道更新數據的時候不須要先取出數據再更新嗎?對了,但凡是有一點點的併發需求,不管是樂觀鎖仍是悲觀鎖,都須要查詢到最新的數據不是嗎,悲觀的加鎖,樂觀的核對 Version。至於全字段回寫數據庫,只是不知道有這種操做而已,hibernate 明明能夠指定局部字段更新的好嗎
  • 報表邏輯真實存在!這也許是一種讓程序員經過關係數據庫把數據分析這活也幹了的一種藉口吧,程序員可不要樂在其中哦
  • 微服務都大行其道了,還在狂釘外鍵,一大堆聯表查詢,sql 語句多達幾百行,想一想都忍不住噗。定義好業務邊界,拆分紅獨立子系統吧,否則到了必定規模,別說 hibernate 幹不了這活,mybatis 手寫 sql 又咋樣,一樣幹不了,不信給某個大廠的高流量數據釘個外鍵試試,看他們技術總監會不會拿刀追。小公司規模每每遠沒有達到那種撐不住的程度,大廠的高訪問量業務數據早已不是這裏逼逼的聯表查詢了。。。
  • 若是公司的數據庫要從 mysql 轉移到 Oracle、MongoDB、sqlserver 或者其餘的數據庫,用 mybatis 的,就問你慌不慌吧。spring 官方支持 jpa 並非沒有依據的,jpa 屏蔽了底層差別。

既然 Jpa 用起來省心,不必硬跟某些大廠的步伐,一步兩步,似魔鬼的步伐!數據庫

就像淘寶技術十年裏說的:網絡

如用戶模塊,老的 member.taobao.com 繼續維護,不添加新功能,新功能在新的模塊上開發,跟老的模塊共用一個數據庫,開發完畢以後放到不一樣的應用集羣上,另開一個域名 member1.taobao.com ,同時再替換老的功能,替換一個,就把老的模塊上的功能關閉一個,逐漸把用戶引導到 member1.taobao.com ,等全部的功能都替換完以後,關閉 member.taobao.com 上。從設計上來看,這個 member1 的二級域名應該是一個過渡狀態,但咱們把 member 域名的代碼下線之後,發現很難把 member1 切換回 member,由於有些地方把連接寫死了,因而後來很長時間裏咱們都是在用 member1.taobao.com 這樣奇怪的域名。一年後,有另一家互聯網公司開始作電子商務了,咱們發現他們的域名也叫 member1.xx.com 、auction1.xx.com ,複製得毫無保留,咱們只能會心一笑。數據結構

沒錯,我用JPA,我也很喜歡JPA的設計哲學。可是同時我以爲Mybatis也是一個很好的框架,高效地解決了不少問題,知足了不少企業的需求,給一個大大的贊。mybatis

技術只是解決問題的一種方式、一種工具,選擇哪一種技術因人而異,存在即合理。併發

相關文章
相關標籤/搜索