jdbc和mybatis效率差距主要因?yàn)槭裁?？你誤會(huì)了。Mybaties也基于JDBC。Java和數(shù)據(jù)庫操作只能通過JDBC完成。Mybaties還需要通過JDBC完成數(shù)據(jù)查詢和更新。Mybaties

jdbc和mybatis效率差距主要因?yàn)槭裁矗?/h2>

你誤會(huì)了。Mybaties也基于JDBC。Java和數(shù)據(jù)庫操作只能通過JDBC完成。Mybaties還需要通過JDBC完成數(shù)據(jù)查詢和更新。Mybaties只基于JDBC，它滲透和封裝了事務(wù)管理接口。JDBC是基礎(chǔ)，MybATES/Hibernate是兩個(gè)具有自己特色的建筑，可以比較！這是基礎(chǔ)。

mybatis和jdbc的區(qū)別？

1. Dao層代碼可以通過現(xiàn)有的插件直接生成，大大提高了編碼效率和準(zhǔn)確性（與手工編碼錯(cuò)誤等相比）。mybatis現(xiàn)有的連接池管理和緩存管理帶來的代碼性能優(yōu)勢(shì)和可靠性（作為一個(gè)工業(yè)開源框架，其代碼已經(jīng)過了很長(zhǎng)時(shí)間的測(cè)試）。一致的編碼風(fēng)格大大減少了代碼差距4。Mybatis自動(dòng)提供一級(jí)和二級(jí)緩存（需要配置和打開）、強(qiáng)大的動(dòng)態(tài)SQL和自動(dòng)會(huì)話管理，比手工維護(hù)更方便、更安全。5面向?qū)ο箝_發(fā)的效率會(huì)更高。畢竟，它可以自動(dòng)生成數(shù)據(jù)庫表的模型對(duì)象，編寫更少的基本SQL。無論是否是團(tuán)隊(duì)合作，都建議使用。6不要重復(fù)從結(jié)果集到域的轉(zhuǎn)換。7如果JDBC想獲得封裝mybatis的關(guān)聯(lián)和集合，你會(huì)有一個(gè)大腦袋

在頭條上問這種問題真是醉了。。順便說一句，胡說八道太多了。

國(guó)內(nèi)設(shè)計(jì)理念為表驅(qū)動(dòng)?？傊壿嬍怯蓴?shù)據(jù)表決定的，實(shí)現(xiàn)是由模型來完成的。事實(shí)上，這與面向?qū)ο蟮乃枷虢厝幌喾?。大多?shù)工程師手中所謂的mybatis的靈活性是，他們不需要考慮如何設(shè)計(jì)模型?！辈还茉鯓樱铱梢杂迷鶶QL來解決這個(gè)問題。模型設(shè)計(jì)太差了，只能靠SQL來修正。JPA是完全對(duì)象驅(qū)動(dòng)的思想。早期設(shè)計(jì)的缺陷會(huì)制約后續(xù)的開發(fā)，不同的數(shù)據(jù)庫可以用不同的方式實(shí)現(xiàn)（事實(shí)上，即使redis也是一樣的）?；卮鹨恍┏Ｒ姷膯栴}。

1. JPA表的連接行為具有不確定性和難以控制性。

您確定使用了spring數(shù)據(jù)JPA嗎？不知道有實(shí)體圖嗎？當(dāng)一個(gè)傻瓜達(dá)到這個(gè)水平時(shí)，他能做什么。

2. JPA子查詢不容易實(shí)現(xiàn)。

我想你沒用過，是嗎？spring數(shù)據(jù)JPA的子查詢不僅可以單獨(dú)定義視圖，還可以進(jìn)行子查詢，甚至可以直接使用jpql。

3. JPA不容易優(yōu)化。

我真的不相信99%的優(yōu)化能超過spring data JPA的優(yōu)化。特別是，普通程序員能否停止談?wù)搩?yōu)化？他們甚至搞不懂MySQL的鎖。表設(shè)計(jì)就像一堆廢話，他們?nèi)匀幻刻焓褂迷鶶QL。你覺得他們很棒嗎？JPA可以將表屬性反映到對(duì)象。當(dāng)然，運(yùn)行時(shí)優(yōu)化是有基礎(chǔ)的。ORM的發(fā)展空間太大了。任何有點(diǎn)技術(shù)知識(shí)的人都知道ORM將擁有越來越多的優(yōu)勢(shì)。有一點(diǎn)經(jīng)驗(yàn)的程序員都知道，在談?wù)撈渌酥?，是時(shí)候先談?wù)摿己玫木S護(hù)了。解決性能問題的方法太多了。

最后，難道你不知道ORM cqrs現(xiàn)在是提倡的嗎？請(qǐng)問，有沒有什么復(fù)雜的問題沒有原生SQL的介入是無法解決的。