最近把手上一個(gè)跑了兩年的項(xiàng)目做了一次數(shù)據(jù)訪問(wèn)層技術(shù)評(píng)估心里突然冒出一個(gè)問(wèn)題同樣是 Java 工程師每天都在用的 MyBatis為什么項(xiàng)目越大XML 文件越讓人頭大如果你也正好處在“換框架”“重構(gòu)數(shù)據(jù)層”的岔路口我建議你把 dbVisitor 放進(jìn)候選清單里試試。dbVisitor 是一款 Java 數(shù)據(jù)訪問(wèn)層框架核心賣(mài)點(diǎn)是零 XML、注解映射、Loambda 類(lèi)型安全 API以及自帶方言適配能力這些特性讓它在很多場(chǎng)景下可以正面硬剛 MyBatis。這篇文章我會(huì)從設(shè)計(jì)思路、代碼改寫(xiě)、遷移踩坑和工程化落地四個(gè)角度聊聊它到底有沒(méi)有資格讓 MyBatis 退居二線。1. MyBatis 的 XML 依賴(lài)從靈活變成了負(fù)擔(dān)1.1 從 XMLConfigBuilder 到 ResultMap初始化階段就埋下的維護(hù)成本MyBatis 的每一次啟動(dòng)都要經(jīng)過(guò) XMLConfigBuilder 解析全局配置文件、加載 Mapper XML、構(gòu)建 MappedStatement。這套流程本身很成熟跑起來(lái)也穩(wěn)定但問(wèn)題不在性能而在“人”的感受。我在項(xiàng)目里維護(hù)了接近 200 個(gè) Mapper XML 文件之后最痛苦的已經(jīng)不再是 SQL 本身而是 ResultMap 的映射關(guān)系。舉一個(gè)很常見(jiàn)的例子。數(shù)據(jù)庫(kù)字段是order_no實(shí)體屬性是orderNo如果不開(kāi)啟駝峰映射你就要在每個(gè) ResultMap 里寫(xiě)一行result columnorder_no propertyorderNo/。一開(kāi)始只有幾個(gè)字段無(wú)所謂但當(dāng)表的列數(shù)超過(guò) 20、實(shí)體又有繼承關(guān)系時(shí)ResultMap 的長(zhǎng)度直接翻倍。更麻煩的是嵌套映射association和collection一旦鋪開(kāi)XML 的縮進(jìn)結(jié)構(gòu)變得比 Java 代碼還難讀。很多團(tuán)隊(duì)靠mapUnderscoreToCamelCase這個(gè)開(kāi)關(guān)規(guī)避了字段映射問(wèn)題但我在實(shí)際項(xiàng)目中還是經(jīng)常遇到“查出來(lái)的字段是 null查了半天才發(fā)現(xiàn) XML 里 column 寫(xiě)錯(cuò)了一個(gè)字母”的情況。列名錯(cuò)誤在編譯期完全不報(bào)錯(cuò)運(yùn)行期也只是靜默返回 null這種問(wèn)題的排查成本特別高。而 XMLConfigBuilder 在啟動(dòng)時(shí)只保證 XML 結(jié)構(gòu)合法不保證列名存在這個(gè)風(fēng)險(xiǎn)藏得很深。1.2 動(dòng)態(tài) SQL 的本質(zhì)是字符串模板開(kāi)發(fā)一時(shí)爽重構(gòu)萬(wàn)丈深淵MyBatis 的動(dòng)態(tài) SQL 一直是它的招牌ifwhereforeach的組合確實(shí)靈活但這種靈活性是有代價(jià)的。我見(jiàn)過(guò)最夸張的一個(gè)查詢(xún)方法XML 里塞了 30 多個(gè)if每個(gè) if 對(duì)應(yīng)一個(gè)可選查詢(xún)條件整段 XML 看起來(lái)像一個(gè)獨(dú)立的編程語(yǔ)言程序。一旦業(yè)務(wù)變化你要做的不是在 Java 里改一行代碼而是打開(kāi) XML 文件在尖括號(hào)的叢林里找對(duì)應(yīng)的條件片段。更難受的是Java 代碼里的 Mapper 接口和 XML 之間的關(guān)聯(lián)是隱式的靠namespace id字符串維系。我做過(guò)一次全局字段重命名IDEA 的全局重命名能改掉 Java 側(cè)XML 里的字段卻只能靠人肉排查。項(xiàng)目里只要有一次這種經(jīng)歷你就知道“類(lèi)型安全”這四個(gè)字值多少錢(qián)。還有 MyBatis 的條件不生效問(wèn)題。熱搜詞里經(jīng)常出現(xiàn)“mybatis條件不生效”我自己也踩過(guò)某個(gè)查詢(xún)加了if teststatus ! null但調(diào)用方傳了Integer類(lèi)型XML 里卻誤寫(xiě)成字符串0結(jié)果條件永遠(yuǎn)滿(mǎn)足或永遠(yuǎn)不滿(mǎn)足。這種問(wèn)題我只能說(shuō)動(dòng)態(tài) SQL 越復(fù)雜出現(xiàn)條件狀態(tài)錯(cuò)亂的概率就越高這不是 MyBatis 的 bug而是模型本身的局限。1.3 緩存與分頁(yè)的“半成品”感還是得靠插件縫縫補(bǔ)補(bǔ)MyBatis 的一級(jí)緩存默認(rèn)是 SqlSession 級(jí)別的作用范圍很小二級(jí)緩存雖然能跨 SqlSession但要手動(dòng)配置 eviction、flushInterval、readOnly 這些參數(shù)配置錯(cuò)了還會(huì)出現(xiàn)臟讀。很多生產(chǎn)項(xiàng)目干脆直接禁用二級(jí)緩存寧可每次都查庫(kù)也不愿意背著“緩存過(guò)期沒(méi)失效”的雷。我見(jiàn)過(guò)一個(gè)項(xiàng)目把二級(jí)緩存打開(kāi)之后某天 updaate 語(yǔ)句沒(méi)走同一個(gè) namespace緩存直接失效臟數(shù)據(jù)暴露出來(lái)最后全團(tuán)隊(duì)一起 debug 到深夜。分頁(yè)方面更典型。MyBatis 本身不提供通用的分頁(yè)能力大家基本都是依賴(lài) PageHelper 或者手寫(xiě) limit。PageHelper 的侵入式分頁(yè)確實(shí)方便但它基于攔截器實(shí)現(xiàn)如果分頁(yè)邏輯復(fù)雜一點(diǎn)比如“先 order by 再 limit”不小心就會(huì)把 order by 一并攔截結(jié)果和預(yù)期完全不一樣。還有多數(shù)據(jù)源場(chǎng)景下 PageHelper 的方言自動(dòng)識(shí)別在分庫(kù)分表代理后面常常會(huì)翻車(chē)。也就是說(shuō)MyBatis 本身把 SQL 控制權(quán)做得很極致但緩存、分頁(yè)這些工程化能力實(shí)際是社區(qū)插件、外部工具在幫忙補(bǔ)位。補(bǔ)得多了調(diào)用鏈就長(zhǎng)出了問(wèn)題你很難判斷是框架的鍋還是插件的鍋。也正是這些親身體驗(yàn)讓我在評(píng)估 dbVisitor 的時(shí)候格外在意它到底把哪些能力做成了框架自帶的“地基”。2. dbVisitor 零 XML 設(shè)計(jì)拆解注解、Lambda 與方言適配2.1 注解映射把結(jié)構(gòu)信息放回實(shí)體旁邊dbVisitor 的第一層設(shè)計(jì)是注解映射。實(shí)體類(lèi)上直接用Table指定表名字段上用Column指定列名和主鍵標(biāo)記字段映射關(guān)系跟實(shí)體本身放在一起。這個(gè)機(jī)制聽(tīng)起來(lái)不算革命性但實(shí)際體驗(yàn)差別很大。MyBatis 的思路是“SQL 和映射關(guān)系獨(dú)立于 Java 代碼”好處是 SQL 可以被 DBA 單獨(dú) review壞處是信息割裂。dbVisitor 的思路是“表結(jié)構(gòu)、列名、實(shí)體字段應(yīng)該在一個(gè)地方集中表達(dá)”這樣你在查看實(shí)體類(lèi)時(shí)就能直接知道它對(duì)應(yīng)哪張表、哪些列是主鍵不需要再跳轉(zhuǎn)到 XML 文件。我自己的項(xiàng)目里大部分實(shí)體其實(shí)并不復(fù)雜字段名和屬性名基本遵循駝峰映射規(guī)則。dbVisitor 的注解在這種場(chǎng)景下不需要寫(xiě)一長(zhǎng)串 ResultMap它會(huì)根據(jù)命名策略自動(dòng)完成默認(rèn)映射。只有遇到真正特殊的字段比如is_deleted映射到deletedFlag才需要顯式寫(xiě)Column。相比之下MyBatis 為了完全可控把每個(gè)映射都交給了用戶(hù)這種“完全可控”到最后往往只是“完全可折騰”。另外注解映射還有一個(gè)隱藏優(yōu)勢(shì)重構(gòu)友好。改了實(shí)體字段名IDE 的重構(gòu)功能可以直接同步到注解值而 XML 里手寫(xiě)的column屬性IDE 根本不知道它和實(shí)體屬性有關(guān)系。這點(diǎn)在后面對(duì)比代碼時(shí)會(huì)更明顯。2.2 為什么 Lambda 類(lèi)型安全 API 能替代手寫(xiě)字符串 SQLdbVisitor 比較核心的設(shè)計(jì)是用 Lambda 方式引用實(shí)體字段。舉個(gè)例子查詢(xún)條件要寫(xiě)WHERE name 張三傳統(tǒng) MyBatis 里可能是${name}或者占位符#{name}而在 dbVisitor 里可以寫(xiě)成User::getName。這個(gè)微小的差異帶來(lái)的價(jià)值非常大。第一編譯期檢查如果實(shí)體里沒(méi)有g(shù)etName方法代碼直接編譯失敗不會(huì)等到運(yùn)行時(shí)才冒出“無(wú)效列名”。第二重構(gòu)安全實(shí)體字段名變了IDE 能自動(dòng)改所有引用處不用全局搜索字符串。第三可讀性eq(User::getName, 張三)這種表達(dá)其實(shí)比WHERE name ?更貼近 Java 工程師的思維習(xí)慣。當(dāng)然Lambda 也不是銀彈它更適合做“條件構(gòu)造”和“字段引用”對(duì)于特別復(fù)雜的原生 SQL 場(chǎng)景dbVisitor 也保留了直接寫(xiě) SQL 的入口。所以它的定位不是“禁止你寫(xiě) SQL”而是“讓 80% 的常規(guī)操作不再需要寫(xiě) SQL”。這一點(diǎn)和 MyBatis 正好相反MyBatis 的默認(rèn)姿勢(shì)是寫(xiě) SQLdbVisitor 的默認(rèn)姿勢(shì)是不寫(xiě) SQL。2.3 方言適配做成引擎能力而不是外圍插件MyBatis 生態(tài)里多數(shù)據(jù)庫(kù)方言適配這件事幾乎全靠 PageHelper 這類(lèi)插件的dialect參數(shù)完成。但插件的本質(zhì)是攔截 SQL攔截之后再改寫(xiě) SQL這背后存在解析風(fēng)險(xiǎn)一旦遇到復(fù)雜子查詢(xún)、嵌套 join插件改寫(xiě)的分頁(yè) SQL 可能不是最優(yōu)的甚至有時(shí)改寫(xiě)完之后結(jié)果集數(shù)量不對(duì)。dbVisitor 則把方言適配放進(jìn)了引擎層。框架內(nèi)部根據(jù)當(dāng)前數(shù)據(jù)源的數(shù)據(jù)庫(kù)類(lèi)型自動(dòng)選擇分頁(yè)方言你在 API 層寫(xiě)的分頁(yè)邏輯不需要關(guān)心底層是 MySQL 還是 Oracle。對(duì)于大多數(shù)業(yè)務(wù)系統(tǒng)來(lái)說(shuō)這意味著“分頁(yè)”從一個(gè)需要引入外部依賴(lài)的動(dòng)作變成了框架原生的能力。我自己在項(xiàng)目里用下來(lái)感受最深的是代碼里不再出現(xiàn)PageHelper.startPage(pageNum, pageSize)這種靜態(tài)方法調(diào)用。分頁(yè)參數(shù)直接傳給查詢(xún) API返回結(jié)果里帶著總數(shù)和當(dāng)前頁(yè)數(shù)據(jù)整個(gè)調(diào)用鏈?zhǔn)峭该鞯腟QL 日志里打印出來(lái)的也是修正后的方言語(yǔ)句排查問(wèn)題時(shí)心里更有底。3. 把 MyBatis 常見(jiàn)寫(xiě)法搬到 dbVisitor四類(lèi)場(chǎng)景對(duì)比實(shí)踐3.1 基礎(chǔ) CRUD代碼量直接砍半先看最普通的單表 CRUD。MyBatis 的經(jīng)典姿勢(shì)是接口定義 XML 映射 SQL 語(yǔ)句。三個(gè)地方來(lái)回切即使只有一個(gè)insert也要寫(xiě)三個(gè)文件片段。// MyBatis 風(fēng)格Mapper 接口 XML public interface UserMapper { User selectById(Long id); int insert(User user); int updateById(User user); int deleteById(Long id); }配套 XML 里至少要有四個(gè) SQL每個(gè)都要手寫(xiě)字段列表和#{}占位符。而在 dbVisitor 里只要把實(shí)體類(lèi)標(biāo)注好通用 CRUD 就自動(dòng)可用。// dbVisitor 風(fēng)格實(shí)體注解 泛型 API Table(u_user) public class User { Column(value id, primary true) private Long id; Column(name) private String name; Column(age) private Integer age; // getter/setter 省略 }接下來(lái)是數(shù)據(jù)訪問(wèn)代碼// 插入 User user new User(); user.setName(張三); user.setAge(28); sqlExecutor.insert(user); // 按主鍵查 User u sqlExecutor.queryByPrimaryKey(User.class, 1L); // 按條件查 ListUser users sqlExecutor.selectList(User.class, query - { query.eq(User::getName, 張三); }); // 更新 u.setAge(29); sqlExecutor.update(u); // 刪除 sqlExecutor.deleteByPrimaryKey(User.class, 1L);這個(gè)對(duì)比很直觀MyBatis 把 SQL 控制權(quán)留給你dbVisitor 把它收編為框架能力。如果你本來(lái)就需要完全手寫(xiě)復(fù)雜 SQLMyBatis 沒(méi)毛病但如果你大部分操作都是標(biāo)準(zhǔn) CRUDdbVisitor 可以幫你省掉大量無(wú)意義的映射文件。我建議團(tuán)隊(duì)里新增一張業(yè)務(wù)表時(shí)優(yōu)先考慮“實(shí)體類(lèi)注解 通用 API”的方式只有特殊查詢(xún)?cè)倏紤]原生 SQL。3.2 分頁(yè)查詢(xún)從靜態(tài)方法到框架原生 APIMyBatis 分頁(yè)通常這樣寫(xiě)PageHelper.startPage(1, 10); ListUser list userMapper.selectPage(new PageQuery()); PageInfoUser page new PageInfo(list);這段代碼最大的坑在于PageHelper.startPage是靜態(tài)的、線程綁定的它會(huì)攔截接下來(lái)執(zhí)行的第一個(gè)查詢(xún)。如果中間有人不小心插入了別的查詢(xún)分頁(yè)參數(shù)就會(huì)作用到錯(cuò)誤的方法上。項(xiàng)目里 “PageHelper 分頁(yè)失效” 的問(wèn)題我這幾年遇到過(guò)不少次基本都是這種隱式狀態(tài)傳遞導(dǎo)致的。dbVisitor 的分頁(yè)則是一個(gè)顯式的查詢(xún)參數(shù)PageResultUser page sqlExecutor.selectPage(User.class, 1, 10, query - { query.lt(User::getAge, 30).like(User::getName, 張); });返回值里直接包含total、pageNumber、pageSize和數(shù)據(jù)列表。這種寫(xiě)法的好處是“分頁(yè)是查詢(xún)的一部分”不存在靜態(tài)狀態(tài)泄露的問(wèn)題。對(duì)于分頁(yè)結(jié)果里還需要再包裝一層業(yè)務(wù)響應(yīng)對(duì)象的情況PageResult的字段也很清晰不需要像PageInfo那樣一層層剝殼。3.3 動(dòng)態(tài)條件構(gòu)造轉(zhuǎn)移 if 邏輯的場(chǎng)景MyBatis 的動(dòng)態(tài) SQL 把條件判斷放進(jìn)了 XML。dbVisitor 的做法完全不同判斷邏輯留在 Java 代碼里用 Lambda 條件構(gòu)造器組裝查詢(xún)條件。同樣是按條件查用戶(hù)列表寫(xiě)法變成了這樣ListUser list sqlExecutor.selectList(User.class, query - { if (StringUtils.hasText(name)) { query.eq(User::getName, name); } if (age ! null) { query.gt(User::getAge, age); } if (statusList ! null !statusList.isEmpty()) { query.in(User::getStatus, statusList); } });代碼就是普通的 Java 邏輯不會(huì)出現(xiàn)if標(biāo)簽也不存在“XML 里的表達(dá)式寫(xiě)錯(cuò)了但運(yùn)行期才發(fā)現(xiàn)”的問(wèn)題。而且這段條件構(gòu)造邏輯可以被抽取成方法復(fù)用比如appendNameCondition、appendAgeCondition這在實(shí)際項(xiàng)目里非常有用。我在做查詢(xún)條件多且組合操作頻繁的列表頁(yè)時(shí)這種寫(xiě)法明顯更順手調(diào)試時(shí)也可以直接在 IDEA 里打斷點(diǎn)看條件構(gòu)造器的狀態(tài)比看一堆 XML 標(biāo)簽直觀得多。3.4 多表聯(lián)查不是只能靠 join XML多表聯(lián)查是很多人不敢離開(kāi) MyBatis 的理由因?yàn)?join SQL 寫(xiě)起來(lái)直接改動(dòng)也直觀。dbVisitor 同樣支持原生 SQL也支持用注解直接掛 SQL 語(yǔ)句Sql(select u.*, o.order_no from u_user u join u_order o on u.id o.user_id where u.id :userId) ListMapString, Object findUserAndOrder(Param(userId) Long userId);如果不想寫(xiě)原生 SQL也可以用 Query 構(gòu)造器表達(dá) join 邏輯但這需要一點(diǎn)學(xué)習(xí)成本。我的建議是復(fù)雜的報(bào)表查詢(xún)、多表頻繁 join 的場(chǎng)景直接寫(xiě)原生 SQL 就好沒(méi)必要強(qiáng)行用 API 繞而簡(jiǎn)單的一對(duì)多查詢(xún)拆成兩次查詢(xún)?nèi)缓笤?Java 里組裝反而比一條大 join 更清晰。dbVisitor 提供了兩種路徑用戶(hù)可以根據(jù)場(chǎng)景自行選擇這是很務(wù)實(shí)的做法。4. 從 MyBatis 遷移 dbVisitor最容易翻車(chē)的映射、TypeHandler 與插件生態(tài)4.1 復(fù)雜嵌套映射MyBatis 的 collection 不是免費(fèi)午餐MyBatis 里collection可以很方便地完成“查訂單時(shí)把訂單明細(xì)一起查出來(lái)”的嵌套結(jié)果映射但它的實(shí)現(xiàn)原理是結(jié)果集分片處理一旦 SQL 里字段順序?qū)戝e(cuò)或者主表主鍵列沒(méi)有在結(jié)果集中返回分片就會(huì)錯(cuò)亂數(shù)據(jù)串行的情況時(shí)有發(fā)生。dbVisitor 不強(qiáng)行模仿這種嵌套映射機(jī)制。按我遷移項(xiàng)目的經(jīng)驗(yàn)對(duì)于一對(duì)多場(chǎng)景更穩(wěn)的方式是分兩條 SQL 查詢(xún)?nèi)缓笤趦?nèi)存里按業(yè)務(wù)鍵做分組組裝。代碼可能比一條 join 多幾行但每個(gè)查詢(xún)都簡(jiǎn)單直接結(jié)果集關(guān)系一目了然。比如查“用戶(hù) 他的訂單”可以先查用戶(hù)再根據(jù)用戶(hù) ID 列表一次性查訂單最后在 Java 里把訂單掛到對(duì)應(yīng)用戶(hù)上。這樣既避免了嵌套映射的隱式規(guī)則也為后續(xù)緩存設(shè)計(jì)提供了更好的切分點(diǎn)。4.2 枚舉與自定義 TypeHandler 的處理差異MyBatis 的 TypeHandler 機(jī)制非常成熟enum 可以配EnumTypeHandler按名字存也可以配EnumOrdinalTypeHandler按 ordinal 存甚至可以自定義 TypeHandler。dbVisitor 對(duì)常見(jiàn)基礎(chǔ)類(lèi)型和枚舉也有內(nèi)置處理但如果你在 MyBatis 里大量依賴(lài)自定義 TypeHandler遷移時(shí)就要仔細(xì)核對(duì)dbVisitor 是否對(duì)每一種自定義類(lèi)型都提供了等價(jià)注冊(cè)方式。我在遷移時(shí)遇到過(guò)一個(gè)小坑某個(gè)狀態(tài)字段使用枚舉MyBatis 側(cè)配置了按 code 值存儲(chǔ)而 dbVisitor 默認(rèn)可能按枚舉 name 存儲(chǔ)查出來(lái)的結(jié)果就會(huì)對(duì)不上。解決方案是在實(shí)體字段的Column上顯式指定類(lèi)型轉(zhuǎn)換策略或者通過(guò)全局配置統(tǒng)一枚舉處理邏輯。這個(gè)細(xì)節(jié)看起來(lái)不起眼但線上數(shù)據(jù)一旦寫(xiě)入方式不對(duì)就會(huì)導(dǎo)致歷史數(shù)據(jù)全量清洗風(fēng)險(xiǎn)很大。所以在任何遷移啟動(dòng)前我建議先做一次“類(lèi)型映射清單”把項(xiàng)目里所有自定義 TypeHandler、枚舉映射、JSON 字段序列化方式全部列出來(lái)逐項(xiàng)確認(rèn)兩邊是否對(duì)齊。這是一件很瑣碎但極其重要的事跳過(guò)去后面大概率要返工。4.3 插件生態(tài)差異PageHelper 和 mybatis-plus 擴(kuò)展不是想帶就能帶MyBatis 強(qiáng)大的地方之一是生態(tài)圍繞它有一堆插件PageHelper、mybatis-plus、通用 Mapper、代碼生成器等。dbVisitor 自己實(shí)現(xiàn)了分頁(yè)、條件構(gòu)造、代碼生成能力所以常規(guī)使用不需要這些插件。但如果你在 MyBatis 項(xiàng)目里深度依賴(lài)某個(gè)插件獨(dú)有的能力比如 mybatis-plus 的lambdaQueryWrapper鏈?zhǔn)秸{(diào)用、自動(dòng)填充功能遷移的時(shí)候就得考慮 dbVisitor 是否有對(duì)標(biāo)方案。以二級(jí)緩存為例MyBatis 的二級(jí)緩存實(shí)現(xiàn)機(jī)制是 namespace 級(jí)別的依賴(lài) Mapper XML 的命名空間隔離。如果你從 MyBatis 遷移過(guò)來(lái)需要想清楚dbVisitor 如果默認(rèn)沒(méi)有同樣的二級(jí)緩存語(yǔ)義你現(xiàn)有的緩存策略要怎么辦我個(gè)人的做法是遷移時(shí)順便重新梳理緩存邊界能用業(yè)務(wù)級(jí)緩存如 Redis替代的就不要依賴(lài) ORM 層緩存。真正需要框架層緩存的時(shí)候并不多與其通過(guò)配置項(xiàng)去模擬 MyBatis 的行為不如把緩存上移到 Service 層控制力更強(qiáng)。4.4 什么情況下我不建議換講完可以遷移的場(chǎng)景也得說(shuō)清楚邊界。如果你的項(xiàng)目屬于以下幾種情況我建議先不要急著告別 MyBatis大量 SQL 是上千行的手寫(xiě) join嚴(yán)重依賴(lài) MyBatis 的動(dòng)態(tài) SQL 語(yǔ)法且已經(jīng)過(guò)多年業(yè)務(wù)打磨這套 SQL 是團(tuán)隊(duì)的核心家底深度使用 MyBatis 的插件生態(tài)比如基于攔截器做了數(shù)據(jù)權(quán)限、SQL 審計(jì)等自定義功能完全遷移到 dbVisitor 需要重寫(xiě)這些底層能力團(tuán)隊(duì)內(nèi)沒(méi)有精力做一次數(shù)據(jù)訪問(wèn)層重構(gòu)業(yè)務(wù)壓力大容不得“順手重構(gòu)”帶來(lái)的風(fēng)險(xiǎn)。我見(jiàn)過(guò)太多“為了換而換”的重構(gòu)項(xiàng)目最后都折在了業(yè)務(wù)排期上。技術(shù)選型這件事沒(méi)有絕對(duì)優(yōu)劣只有匹配度。dbVisitor 更適合新項(xiàng)目、標(biāo)準(zhǔn) CRUD 占比高的系統(tǒng)、基礎(chǔ)設(shè)施想輕量化的團(tuán)隊(duì)MyBatis 更適合復(fù)雜 SQL 密集、生態(tài)依賴(lài)深、團(tuán)隊(duì)積累了大量 XML 資產(chǎn)的老項(xiàng)目。5. 多數(shù)據(jù)源與工程化能力dbVisitor 值得關(guān)注的真底氣5.1 多數(shù)據(jù)源路由比 mybatis-spring 這套組合更輕多數(shù)據(jù)源在 MyBatis 生態(tài)里通常需要引入DS注解、AbstractRoutingDataSource 或者 shardingsphere 這類(lèi)重組件。dbVisitor 對(duì)多數(shù)據(jù)源的抽象更接近“數(shù)據(jù)源即上下文”的理念不同的數(shù)據(jù)源連接可以通過(guò)配置和注解動(dòng)態(tài)切換不需要為每個(gè)數(shù)據(jù)源單獨(dú)配置一套 SqlSessionFactory。我實(shí)際驗(yàn)證過(guò)讀寫(xiě)分離的場(chǎng)景主庫(kù)負(fù)責(zé)寫(xiě)從庫(kù)負(fù)責(zé)讀。dbVisitor 里把主從數(shù)據(jù)源注冊(cè)好之后查詢(xún)類(lèi)操作可以路由到從庫(kù)寫(xiě)操作自動(dòng)落到主庫(kù)。關(guān)鍵是沒(méi)有 MyBatis 那種 “一個(gè)數(shù)據(jù)源一套 SqlSessionFactory” 的管理復(fù)雜度數(shù)據(jù)源切換像換一個(gè)參數(shù)一樣簡(jiǎn)單。對(duì)于中小團(tuán)隊(duì)來(lái)說(shuō)這套機(jī)制維護(hù)成本低很多。不過(guò)也得提醒一句多數(shù)據(jù)源這個(gè)東西一旦涉及分布式事務(wù)復(fù)雜度是繞不開(kāi)的不管用什么框架都要面對(duì)。dbVisitor 解決的是“路由”的便利性不是“分布式事務(wù)”的銀彈。5.2 樂(lè)觀鎖、邏輯刪除等開(kāi)箱能力MyBatis 實(shí)現(xiàn)樂(lè)觀鎖需要自己在 SQL 里寫(xiě)where version ?dbVisitor 則提供了更直接的樂(lè)觀鎖支持。實(shí)體類(lèi)里加上版本字段更新時(shí)框架自動(dòng)帶版本條件更新成功影響行數(shù)為 0 時(shí)再重試或報(bào)錯(cuò)。同樣邏輯刪除字段也可以做成全局配置查詢(xún)時(shí)自動(dòng)過(guò)濾已刪除數(shù)據(jù)不需要每個(gè) SQL 都手寫(xiě)deleted 0。這些能力做進(jìn)框架而不是放給開(kāi)發(fā)者最大的好處是業(yè)務(wù)代碼不會(huì)寫(xiě)歪。很多項(xiàng)目里的 soft delete 是每個(gè)查詢(xún)?nèi)巳饧拥囊坏┞┘泳统霈F(xiàn)臟數(shù)據(jù)。框架層統(tǒng)一處理后至少默認(rèn)行為是一致的這對(duì)于新成員加入后的代碼規(guī)范很有幫助。5.3 Spring Boot 集成與最小成本驗(yàn)證路徑dbVisitor 對(duì)接 Spring Boot 很簡(jiǎn)單引入 starter 依賴(lài)、配置數(shù)據(jù)源、啟動(dòng)即可。最小成本驗(yàn)證的路徑我一般推薦三步走第一步新建一個(gè)只包含單表 CRUD 的 demo把實(shí)體注解、通用 API、分頁(yè)查詢(xún)跑通感受一下和一個(gè)普通的 MapperXML 項(xiàng)目相比代碼量差多少。第二步把項(xiàng)目里一個(gè)真實(shí)的列表頁(yè)查詢(xún)遷移過(guò)來(lái)對(duì)比一下 SQL 日志、接口響應(yīng)時(shí)間、整體開(kāi)發(fā)體驗(yàn)。第三步挑一個(gè)只用了基礎(chǔ) CRUD 的模塊整體切換在灰度環(huán)境中觀察一段時(shí)間確認(rèn)沒(méi)有回歸問(wèn)題后再逐步擴(kuò)展。整個(gè)過(guò)程我建議控制在一到兩周內(nèi)畢竟數(shù)據(jù)訪問(wèn)層只是系統(tǒng)的一部分真正決定框架好壞的往往不是某個(gè)炫酷 API而是日常開(kāi)發(fā)中的順手程度和問(wèn)題排查效率。dbVisitor 在設(shè)計(jì)上更貼近“現(xiàn)代 Java 默認(rèn)值”的定位而不是像 MyBatis 那樣把選擇權(quán)全部交給你兩種哲學(xué)沒(méi)有對(duì)錯(cuò)但有適配場(chǎng)景的差異。如果讓我重新做一次技術(shù)選型我會(huì)把“維護(hù)成本”放在第一條。MyBatis 給了我完全控制 SQL 的自由我也為這份自由付過(guò)不少排查時(shí)間。dbVisitor 用注解和類(lèi)型安全 API 幫我把一部分自由換成了工程安全感這種取舍目前來(lái)看我覺(jué)得值。如果你也在被 XML 映射文件折磨不妨抽個(gè)下午用真實(shí)業(yè)務(wù)表試一下 dbVisitor跑一次分頁(yè)、改一條動(dòng)態(tài)查詢(xún)你應(yīng)該很快就能感受到我說(shuō)的這種差異。