SpringData JPA也能寫sql，為什么還要用mybatis？

FrozenMap 2022-06-28 14:13 回答0 收藏1

收藏問題

10條回答

weapon

回答于2022-06-28 14:13

頭條上問這種問題也是醉了。?？吹搅隧槺愦鹨徊ǎ钩兜娜颂?。

國(guó)內(nèi)的設(shè)計(jì)思路是table driven的，簡(jiǎn)單來說，用數(shù)據(jù)表定邏輯，用模型做實(shí)現(xiàn)，實(shí)際這是和面向?qū)ο笙喾吹乃悸?。mybatis所謂的靈活性在大多數(shù)工程師手里就是不用考慮模型如何設(shè)計(jì)，“反正我用原生sql都能解決”，模型設(shè)計(jì)的爛的一逼，全靠sql去修修補(bǔ)補(bǔ)。而jpa是完全object driven的思路，前期設(shè)計(jì)的缺陷會(huì)很制約后續(xù)開發(fā)，并且不同的數(shù)據(jù)庫(kù)可做不同的實(shí)現(xiàn)（實(shí)際是哪怕是redis也是一樣的）?；卮饚讉€(gè)常見sb問題。

1.jpa表連接行為不確定，難以控制。

你確定你用過spring data jpa？不知道有EntityGraph ？傻瓜到這種程度了還能咋的。

2.jpa子查詢不好實(shí)現(xiàn)。

我估計(jì)你都沒用過吧？spring data jpa的子查詢既可以多帶帶定義視圖，也可以做subquery，甚至直接用jpql。

3.jpa不好優(yōu)化。

我真不信99%得優(yōu)化能超過spring data jpa的優(yōu)化，尤其是一般般的程序員能別把優(yōu)化放嘴上么，連mysql的鎖都搞不清楚，表設(shè)計(jì)的跟坨屎一樣還天天原生sql，覺得自己很牛逼么？jpa是可以把表屬性反應(yīng)到對(duì)象的，天然就有運(yùn)行時(shí)優(yōu)化的底子在，ORM能發(fā)展的空間太大了，稍微有點(diǎn)技術(shù)認(rèn)知的都知道ORM會(huì)優(yōu)勢(shì)越來越大。稍微有些經(jīng)歷的程序員都知道現(xiàn)在是先說好維護(hù)才說其他的，能解決性能的方法太多了好么。

最后，難道不知道現(xiàn)在提倡ORM+CQRS么？請(qǐng)問，有啥復(fù)雜的解決不了，都不需要native sql介入好么。

評(píng)論0 贊同0

加載中...

Dongjie_Liu

回答于2022-06-28 14:13

個(gè)人認(rèn)為mybatis可以做到代碼與SQL解耦，單表查詢用jpa倒是沒什么，要是寫統(tǒng)計(jì)或者復(fù)雜查詢之類的jpa就不太友好了，需要代碼邏輯跟SQL耦合起來，代碼可讀性和可維護(hù)性不好。最近基于jdbcTemplate做了一套自定義動(dòng)態(tài)查詢，也將sql放在了配置文件中，也是為了降耦和提高代碼可讀性，還可以根據(jù)業(yè)務(wù)場(chǎng)景定制很多功能。

評(píng)論0 贊同0

加載中...

ideaa

回答于2022-06-28 14:13

這個(gè)問題需要真實(shí)去使用過，在使用的過程中會(huì)發(fā)現(xiàn)各自框架的痛點(diǎn)，當(dāng)你尋找解決方案的時(shí)候，你會(huì)看其它框架有沒有解決這個(gè)問題，這樣你就會(huì)領(lǐng)悟到另一個(gè)框架的優(yōu)勢(shì)了。

分享一個(gè)真實(shí)的實(shí)戰(zhàn)經(jīng)歷：

項(xiàng)目剛開始使用原始JDBC方式操作數(shù)據(jù)庫(kù)，自己手動(dòng)建表不說，手動(dòng)組裝對(duì)象太痛苦，表字段和對(duì)象的關(guān)系映射寫一堆代碼，這時(shí)候就會(huì)想如果有個(gè)框架能自動(dòng)把表和對(duì)象關(guān)系自動(dòng)映射，并且能夠封裝好使用方法，在初始化時(shí)還能自動(dòng)建表就更好了。

查找方案時(shí)發(fā)現(xiàn)了SpringDataJpa，仿佛打開了新世界的大門，原來通過寫SQL查詢?cè)俎D(zhuǎn)成對(duì)象的增刪改查都不用寫了，表字段和對(duì)象的映射也不需要手工寫代碼去匹配可，直接使用，而且可以開啟初始化時(shí)自動(dòng)創(chuàng)建數(shù)據(jù)庫(kù)表。原來需要消耗時(shí)間的數(shù)據(jù)庫(kù)操作代碼現(xiàn)在完全不用寫了，簡(jiǎn)單的條件查詢，直接調(diào)用封裝的方法，快到起飛。但是隨著業(yè)務(wù)數(shù)據(jù)的不斷增多，要查詢的條件也越來越復(fù)雜，查詢時(shí)效越來越慢，漸漸對(duì)查詢性能也有了要求。然后就想，在這樣的使用便利上，如果有能便于優(yōu)化數(shù)據(jù)庫(kù)查詢性能的解決方案就好了。

再次找解決方案，發(fā)現(xiàn)了MyBatis，感覺發(fā)現(xiàn)了另一個(gè)新世界。雖然，它不能直接把表和對(duì)象的關(guān)系映射自動(dòng)封裝好，但是它可以直接把操作結(jié)果映射成需要的對(duì)象，只需要建立對(duì)應(yīng)的數(shù)據(jù)對(duì)象DTO就行，并且多表關(guān)聯(lián)查詢、復(fù)雜條件查詢都可以寫SQL解決，最重要的是SQL和邏輯代碼分析，維護(hù)也很方便，SQL優(yōu)化交給專業(yè)的DBA就行，再次好用到起飛。

突然有一天，公司強(qiáng)制要求數(shù)據(jù)庫(kù)從oracle換成MySQL，發(fā)現(xiàn)Mybatis因?yàn)槎际菍懙募僑QL，原來的SQL語法是oracle的，現(xiàn)在都要改，太依賴數(shù)據(jù)庫(kù)了，不便于換數(shù)據(jù)源。這時(shí)想起了不依賴數(shù)據(jù)源的JPA。

總結(jié)一下個(gè)人看法：

JPA使用完全面向?qū)ο蟮牡脑O(shè)計(jì)思想，一個(gè)表就是一個(gè)對(duì)象，所有的操作直接操作對(duì)象就行，方便、快捷，也不需要關(guān)注底層數(shù)據(jù)源問題，但是表之間的關(guān)系復(fù)雜了、查詢復(fù)雜了，這樣的操作不是它的強(qiáng)項(xiàng)。

Mybatis是半面向?qū)ο?、半面向SQL，SQL與邏輯代碼分離，查詢結(jié)果映射成對(duì)象，所有操作上層是對(duì)象，下層用SQL，數(shù)據(jù)查詢優(yōu)化上更加實(shí)用，因?yàn)槭菍懺鶶QL，所以換數(shù)據(jù)源可能麻煩。

還是業(yè)內(nèi)的那句老話，沒有絕對(duì)“銀彈”，只有適合當(dāng)前業(yè)務(wù)發(fā)展需要的技術(shù)。

評(píng)論0 贊同0

加載中...

BigTomato

回答于2022-06-28 14:13

JPA傾向于用實(shí)體對(duì)象去查數(shù)據(jù)，不便于查詢性能優(yōu)化，而mybatis是寫在配置文件里的，只要代碼邏輯層規(guī)范，更容易拿到需要優(yōu)化的sql，而且這樣更符合開發(fā)人員的思維邏輯，寫java代碼的地方就是寫java代碼的，放sql語句的就是放sql語句的。最重要的一點(diǎn)，在實(shí)際項(xiàng)目的實(shí)踐中，我能明顯感覺出mybatis查詢的效率要優(yōu)于JPA和Hibernate。

評(píng)論0 贊同0

加載中...

DevWiki

回答于2022-06-28 14:13

看了一些其他人的回答，噴子蠻多的，噴了輪子還不夠還要噴別人sb，不會(huì)用。沒必要搞歧視，都是輪子，用來解放生產(chǎn)力的。輪子好不好，根據(jù)具體場(chǎng)景來。

但是從普適性上來看，如果本來比較簡(jiǎn)單的事情，用了工具之后反而更復(fù)雜了，那就應(yīng)該反思了。沒錯(cuò)，這里我說的就是jpa。

Jpa確實(shí)很多概念都不錯(cuò)，如果你拿它做個(gè)Demo，會(huì)發(fā)現(xiàn)確實(shí)是生產(chǎn)力解放工具，一旦你用到真實(shí)項(xiàng)目上，可能就不盡人意了。除非你的項(xiàng)目業(yè)務(wù)很簡(jiǎn)單，不涉及復(fù)雜的表關(guān)系，因?yàn)樵趩伪淼哪Ｐ蜕蟡pa確實(shí)表現(xiàn)得很優(yōu)雅，但是哪個(gè)實(shí)際的業(yè)務(wù)會(huì)如此簡(jiǎn)單？做過項(xiàng)目的人都有經(jīng)驗(yàn)，不用我多說。

看到這里，很多人就會(huì)噴了，Jpa你會(huì)不會(huì)用呀，querydsl，enetitygraphql，hql這些都可以用來做復(fù)雜查詢，你用過沒？

嗯，其實(shí)我現(xiàn)在就在用這些東西。這些東西確實(shí)能解決問題，但也只是解決能不能的問題。這就回到前面我所說的，本來簡(jiǎn)單事情，反而因?yàn)楣ぞ吒鼜?fù)雜了，原來只用寫sql就能解決的問題，現(xiàn)在是不用寫sql了，但是得寫所謂hql，dsl，graqhql，這就造成你不光要搞懂sql怎么寫，還要搞懂用這些玩意怎么去間接生成你想要sql。

其實(shí)用上面這些和jpa捆綁在一起的東西的，本身就是jpa短板導(dǎo)致的無奈之舉，這些東西本身和jpa理念是互相矛盾的。

說到這，有些人的言論就變成了，你不會(huì)用怪誰，水平不行怪輪子。這是混淆概念，好不好用是工具自身便捷與否，和用的人水平有什么關(guān)系。

所以，究竟jpa好不好用，得看你用來做什么了。

評(píng)論0 贊同0

加載中...

zhiwei

回答于2022-06-28 14:13

兩者并沒有明顯的劣勢(shì)。從技術(shù)角度講我更喜歡Jpa，因?yàn)樗菢?biāo)準(zhǔn)，功能上會(huì)強(qiáng)一些。但是在企業(yè)開發(fā)架構(gòu)選型上可能會(huì)選擇mybatis，因?yàn)樗?jiǎn)單上手快，半吊子程序員也能寫出性能不錯(cuò)的代碼，學(xué)習(xí)成本低，也為企業(yè)節(jié)約成本。反觀Jpa能掌握精髓的人少而貴。。。。

評(píng)論0 贊同0