問答專欄Q & A COLUMN
如果讓我來說，我推薦你使用sqltoy-orm，增刪改和對(duì)象加載簡(jiǎn)單查詢jpa模式，查詢則比mybatis強(qiáng)無數(shù)倍，更加直觀簡(jiǎn)潔，另外具有緩存翻譯大幅提升查詢性能，還有很多人不敢想象的分頁優(yōu)化級(jí)別（很多僅僅優(yōu)化了count處理就以為很強(qiáng)了，見了sqltoy的分頁優(yōu)化才屬于見到了不可想象的事情）！
github上搜索sagacity-sqltoy！
https://github.com/sagframe/sagacity-sqltoy
gitee地址：
https://gitee.com/sagacity/sagacity-sqltoy
評(píng)論0
加載中...
我自己開發(fā)的情況下用JPA的比例比mybaits更多，首先我比較討厭mybaits那種標(biāo)簽和SQL混用的風(fēng)格，其次是JPA的也是可以使用原生SQL嵌入實(shí)習(xí)復(fù)雜查詢的，最后是JPA穩(wěn)定性比較好
評(píng)論0
加載中...
看你團(tuán)隊(duì)喜好吧，Mybatis 容易上手，也更加靈活。
JPA 也不錯(cuò)，畢竟屬于 Spring 全家桶一部分，像使用對(duì)象一樣寫 SQL 這種體驗(yàn)也蠻好的。
都可以執(zhí)行原生 SQL。
怎么喜歡怎么來。
不必糾結(jié)。
評(píng)論0
加載中...
都可以吧，mybatis我更多用來寫報(bào)表統(tǒng)計(jì)，或者復(fù)雜的關(guān)聯(lián)查詢。如果架構(gòu)是微服務(wù)，并且通過業(yè)務(wù)解耦來避免了頻繁的事務(wù)，用spring data是非常好的選擇[呲牙]最后，為什么非要二選一呢？看看mybatis plus吧，成功的糅合了mybatis的靈活與jpa的快捷，還有代碼生成器，非常建議題主去試試！
評(píng)論0
加載中...
大型項(xiàng)目用Mybatis，例如多表關(guān)聯(lián)查詢等，靈活。小型項(xiàng)目JPA，不需要寫SQL，操作對(duì)象即可。
評(píng)論0
加載中...
技術(shù)選型需要結(jié)合多方面來考慮，這里我試著列舉一些方面，僅供參考。
是否需要兼容多種數(shù)據(jù)庫。如果需要兼容，優(yōu)先考慮spring data jpa。因?yàn)閙ybatis想要兼容數(shù)據(jù)庫需要寫多套sql腳本，工作量很大。
開發(fā)團(tuán)隊(duì)的經(jīng)驗(yàn)。開發(fā)團(tuán)隊(duì)成員過往開發(fā)中，對(duì)哪個(gè)orm框架更熟悉。一般來說，mybatis上手比較容易，jpa/hibernate雖然不用寫sql語句，但是配置復(fù)雜，各個(gè)狀態(tài)轉(zhuǎn)換難以理解，出現(xiàn)錯(cuò)誤也難以調(diào)試，對(duì)開發(fā)人員能力要求較高。
性能考慮。作為orm框架，jpa/hibernate需要把數(shù)據(jù)庫行完全映射成java對(duì)象，占用內(nèi)存較大，特別是進(jìn)行關(guān)鍵查詢的情況下。當(dāng)然，這可以通過懶加載、查詢指定字段等方式優(yōu)化，但是和上面一樣，對(duì)人員要求較高。另外hibernate生成的sql語句可讀性也較差，不利于檢查問題。
其他雜項(xiàng)考慮。jpa對(duì)邏輯刪除支持較差; mybatis編寫ResultMap過于繁瑣等等。
總結(jié)一下，spring data jpa開發(fā)效率高，代碼量少，但是代價(jià)是學(xué)習(xí)成本和優(yōu)化成本比較高。mybatis代碼量大一些，不好兼容多種數(shù)據(jù)庫，但是手動(dòng)編寫sql相對(duì)靈活，上手簡(jiǎn)單。
評(píng)論0
加載中...
如果做的是管理類型的系統(tǒng)特別是動(dòng)態(tài)查詢復(fù)雜的， mybatis 比較好些，其他推薦用Spring data jpa
評(píng)論0
加載中...
0
回答0
回答0
回答1
回答0
回答5
回答10
回答0
回答0
回答8
回答
