有開(kāi)發(fā)者引用物理學(xué)隱喻：“粒子的位置與動(dòng)量不可同時(shí)確定”，暗示在框架設(shè)計(jì)中，通用性與專用性難以兼得。更有人直言，任何嘗試“大一統(tǒng)”的框架，最終都會(huì)淪為“四不像”，不僅丟掉了數(shù)據(jù)庫(kù)的強(qiáng)事務(wù)優(yōu)勢(shì)，也沒(méi)能發(fā)揮出例如 Elasticsearch 的能力。

面對(duì)這些質(zhì)疑，dbVisitor 依然堅(jiān)定地提出了"One API Access Any DataBase"的愿景。為什么我敢這么說(shuō)？今天我們就來(lái)拆解這個(gè)爭(zhēng)議，聊聊 dbVisitor 敢于挑戰(zhàn)“大一統(tǒng)”的底氣究竟在哪里。

我們對(duì) API 的誤解

要理解為什么 “大一統(tǒng)” 是可行的，我們首先需要厘清兩個(gè)長(zhǎng)期以來(lái)混淆視聽(tīng)的誤區(qū)。

1. API 業(yè)務(wù)化

目前的 Java 數(shù)據(jù)庫(kù)訪問(wèn)領(lǐng)域，出現(xiàn)了一種明顯的趨勢(shì)：API 越來(lái)越“業(yè)務(wù)化”。

什么是業(yè)務(wù)化？

為了解決特定領(lǐng)域的復(fù)雜查詢問(wèn)題，數(shù)據(jù)庫(kù)訪問(wèn)框架開(kāi)始追求極致的開(kāi)發(fā)效率。 例如一些優(yōu)秀項(xiàng)目：SqlToy-ORM 在處理極致的分頁(yè)優(yōu)化、緩存翻譯以及層次化數(shù)據(jù)查詢（如遞歸查詢）方面表現(xiàn)卓越， 往往能用極簡(jiǎn)的配置解決令人頭禿的 SQL 難題；而 Easy-Query 則在類型安全的動(dòng)態(tài)查詢構(gòu)建上做到了極致，讓你在 Java 代碼中就能以結(jié)構(gòu)化的方式編寫出極其復(fù)雜的業(yè)務(wù)邏輯。

價(jià)值：對(duì)于特定領(lǐng)域的復(fù)雜查詢（如多表關(guān)聯(lián)、動(dòng)態(tài)聚合、行轉(zhuǎn)列）它們甚至能通過(guò)很少的代碼替代幾十行原生 SQL。這種效率提升是巨大的，值得充分肯定。

局限：這種“神器”級(jí)別的 API 往往與數(shù)據(jù)庫(kù)的特性強(qiáng)綁定。例如 MySQL 的復(fù)雜查詢邏輯，直接照搬到 MongoDB 或 Elasticsearch 上是完全行不通的。

dbVisitor 的選擇：回歸基座

回顧 Hibernate、MyBatis、DBUtils 甚至 JDBC 本身，這些生命力持久的項(xiàng)目都有一個(gè)共性：職責(zé)單一、目標(biāo)明確。它們不做業(yè)務(wù)邏輯，而是專注做基座。

MyBatis Plus 在國(guó)內(nèi)的巨大成功，正是建立在 MyBatis 這個(gè)堅(jiān)實(shí)的 “非業(yè)務(wù)化” 基座之上。MyBatis 負(fù)責(zé)映射，MP 負(fù)責(zé)提供更高級(jí)的特性和封裝。

通用性的價(jià)值在于做“房屋的骨架”。dbVisitor 的目標(biāo)并非替代 Easy-Query 這類工具去解決具體業(yè)務(wù)的復(fù)雜查詢，而是立志成為新時(shí)代的數(shù)據(jù)訪問(wèn)基座。 只有基座穩(wěn)固且統(tǒng)一，上層的業(yè)務(wù)生態(tài)（就像 MyBatis 生態(tài)）才能在不同數(shù)據(jù)源上百花齊放。

2. “簡(jiǎn)單模式無(wú)用論” 的謬誤

反對(duì)者常由兩個(gè)觀點(diǎn)：

• “CRUD 太簡(jiǎn)單，統(tǒng)一了也沒(méi)價(jià)值”

• “統(tǒng)一 API 無(wú)法跨越數(shù)據(jù)庫(kù)特性的鴻溝”

反駁觀點(diǎn)一：簡(jiǎn)單 CRUD 的普世價(jià)值

如果你的世界里只有 MySQL 和 Oracle，那么非常確實(shí)，JDBC 已經(jīng)統(tǒng)一了，再造輪子沒(méi)意義。 但如果你的技術(shù)棧加入了MongoDB、Elasticsearch、Redis呢？

MongoDB 插入一條數(shù)據(jù)用 “db.collection.insertOne()”

Elasticsearch 插入一條數(shù)據(jù)用 “POST /indexName/_doc ...”

Redis 插入一條數(shù)據(jù)用 “set xxx”命令

這些“簡(jiǎn)單”的操作，API 風(fēng)格天差地別。在"One API Access Any DataBase"的愿景下，能用統(tǒng)一的insert(entity)完成上述所有操作，本身就具有極高的普世價(jià)值，它消除了認(rèn)知切換的成本。

反駁觀點(diǎn)二：API 不僅僅是查詢構(gòu)造器

這是一個(gè)巨大的思維誤區(qū)：“統(tǒng)一 API” 不等于 “統(tǒng)一成某一特定的接口”。

查詢構(gòu)造器是不是 API？當(dāng)然是！

Mapper 接口（Dao）是不是 API？當(dāng)然是！

MyBatis 的 Mapper XML 綁定是不是 API？當(dāng)然是！

底層的JDBC Connection是不是 API？更是！

人們鄙棄 Mapper + XML，往往是因?yàn)樗鼘懫饋?lái)繁瑣（重復(fù)勞動(dòng)），但在架構(gòu)層面，Mapper 接口綁定 DSL是最符合“行為中心”的 API 設(shè)計(jì)。 它將“業(yè)務(wù)意圖”（方法名）與“具體實(shí)現(xiàn)”（SQL/DSL）剝離。

只要我們不再執(zhí)著于用 Java 代碼去描述一切查詢，而是接受“API 定義行為”這個(gè)理念，跨越數(shù)據(jù)庫(kù)特性的鴻溝就可以迎刃而解。

dbVisitor 的核心思想

沒(méi)有靈丹妙藥，任何試圖發(fā)明一種 “萬(wàn)能 Java 語(yǔ)法”來(lái)生成所有數(shù)據(jù)庫(kù)查詢的嘗試，都注定失敗。

dbVisitor 之所以敢說(shuō)“可以”，是因?yàn)槠浜诵乃枷氩⒎侨?strong>消滅差異尋求發(fā)明萬(wàn)能語(yǔ)法， 而是通過(guò)JDBC 標(biāo)準(zhǔn)化和分層抽象來(lái)管理差異。并通過(guò)獨(dú)特的雙層適配器架構(gòu)來(lái)彌合鴻溝：

JDBC 標(biāo)準(zhǔn)化

這層是 dbVisitor 達(dá)成 “One API Access Any DataBase” 愿景的根基。

復(fù)用 JDBC 標(biāo)準(zhǔn)

沒(méi)有發(fā)明新協(xié)議，而是為 NoSQL（MongoDB, Elasticsearch, Redis）編寫了遵循 JDBC 規(guī)范的驅(qū)動(dòng)。 并使用這些數(shù)據(jù)庫(kù)官方原始的 DSL 語(yǔ)言來(lái)進(jìn)行數(shù)據(jù)庫(kù)操作。這些驅(qū)動(dòng)在內(nèi)部也僅僅是將 JDBC 的操作映射到各自的原生 SDK 調(diào)用上，并將返回值映射成 JDBC 標(biāo)準(zhǔn)方式。

Request/Response 模型

為了簡(jiǎn)化異構(gòu)數(shù)據(jù)源的接入，復(fù)雜的 JDBC 狀態(tài)管理被簡(jiǎn)化為輕量級(jí)的 Request/Response 模型。這使得你可以用很少的代碼即可接入一個(gè)全新的非標(biāo)準(zhǔn)的數(shù)據(jù)源。 新的數(shù)據(jù)源，甚至直接被HikariCP管理。在使用它們的時(shí)候，除了查詢語(yǔ)法不是 SQL 意外其它完全一致。

正是基于上述特征 dbVisitor 在進(jìn)行適配 Elasticsearch 時(shí)只使用了約 20 個(gè)類，總共 2300 行代碼，極其輕量。

One API

這里的“One API”并非指用一個(gè)死板的接口去涵蓋一切，而是指構(gòu)建 一種統(tǒng)一的數(shù)據(jù)交互標(biāo)準(zhǔn)， dbVisitor 的設(shè)計(jì)哲學(xué)認(rèn)為，真正的統(tǒng)一不是強(qiáng)行把所有數(shù)據(jù)庫(kù)操作都塞進(jìn)同一個(gè)狹窄的入口，而是通過(guò)分層抽象在不同的維度上提供統(tǒng)一的體驗(yàn)。

dbVisitor 為不同的場(chǎng)景設(shè)計(jì)了不同級(jí)別的抽象接口，以應(yīng)對(duì)不同的行為需求：

LambdaQuery（屏蔽差異） Mapper / XML（管理差異） JDBC Template（透?jìng)鲌?zhí)行） 統(tǒng)一 API ≠ 統(tǒng)一能力

盡管 dbVisitor 統(tǒng)一了 insert/update/commit 等調(diào)用形式，但它不能改變底層數(shù)據(jù)庫(kù)的物理特性。 對(duì)于 MongoDB、Elasticsearch 等弱事務(wù)或無(wú)事務(wù)的存儲(chǔ)，調(diào)用commit()可能只是邏輯上的空操作，并不意味著具備了關(guān)系型數(shù)據(jù)庫(kù)的 ACID 強(qiáng)一致性保障。

實(shí)戰(zhàn)：多維度的統(tǒng)一體驗(yàn)

讓我們通過(guò)代碼，看看這套理念是如何落地的。

1. 簡(jiǎn)單維度(類型安全)

無(wú)論底層是 MySQL 還是 Elasticsearch，標(biāo)準(zhǔn)的 CRUD 代碼完全一致。

2. 業(yè)務(wù)維度（行為為中心）

當(dāng)我們需要發(fā)揮 ES 的聚合能力或 MySQL 的復(fù)雜 Join 時(shí)，Mapper 接口是最佳選擇。dbVisitor 提供了三種使用 Mapper 的姿勢(shì)，你可以根據(jù)業(yè)務(wù)復(fù)雜度靈活混用。

方式一：純 Java 構(gòu)建

這是 dbVisitor 一種方式，通過(guò)繼承 BaseMapper并利用 Java 8 的default 方法，你可以在 Mapper 接口內(nèi)部直接使用查詢構(gòu)造器完成 DAL 邏輯。 這種方式既避免了 XML 的繁瑣，又不像注解那樣將 SQL 硬編碼在 Java 文件中，完美實(shí)現(xiàn)了“零 SQL”開(kāi)發(fā)。

方式二：基于注解

對(duì)于中等復(fù)雜度的查詢，直接在接口方法上使用注解是最簡(jiǎn)潔的方式。你無(wú)需編寫額外的 XML 文件，即可完成 SQL 或 DSL 的綁定。

方式三：基于 Mapper 文件

當(dāng) SQL 變得極度復(fù)雜（如幾百行的報(bào)表 SQL），或者公司有嚴(yán)格的 DBA 審查流程（需分離 SQL 文件）時(shí)，XML 依然是不可替代的方案。

Java 接口（定義行為）：

XML 實(shí)現(xiàn)（定義邏輯）：這里展示了 dbVisitor 的強(qiáng)大之處：在 XML 中寫不同數(shù)據(jù)庫(kù)的方言。

3. 靈活維度：(原生體驗(yàn))

這是 dbVisitor 的“逃生艙”。當(dāng)上層所有的抽象都無(wú)法滿足你的特殊需求時(shí)，比如需要極致的性能優(yōu)化、使用數(shù)據(jù)庫(kù)特有的非標(biāo)指令，或者集成QueryDSL等第三方框架，你可以退回到這層。

場(chǎng)景一：原生 SQL/Shell 透?jìng)?/p>

直接下發(fā)數(shù)據(jù)庫(kù)能識(shí)別的原生命令，無(wú)需任何轉(zhuǎn)譯。

場(chǎng)景二：底層 API 可達(dá)

你可以隨時(shí)打破封裝，直接操作底層的Connection。對(duì)于 NoSQL 數(shù)據(jù)源，dbVisitor 的驅(qū)動(dòng)層也遵循了 JDBC 的Wrapper規(guī)范，允許你 unwrap 出官方的原生驅(qū)動(dòng)對(duì)象。

為何選擇 dbVisitor？

很多人會(huì)問(wèn)：“這不就是把 MyBatis 和 Spring 縫合了一下嗎？” 其實(shí)并非如此。dbVisitor 不是簡(jiǎn)單的“膠水”，而是基于統(tǒng)一架構(gòu)的重新設(shè)計(jì)。

1. 獨(dú)立的雙層適配能力

dbVisitor 是One API + Driver。 即便你不打算替換現(xiàn)在的 MyBatis，你依然可以單獨(dú)使用 dbVisitor 的JDBC Driver。把它放入你的 Spring Boot + MyBatis 項(xiàng)目中，你的 MyBatis 立刻就具備了操作 MongoDB 和 Elasticsearch 的能力！ 這是一種“降維打擊”般的兼容性。

2. 底層架構(gòu)的高度統(tǒng)一

如果你嘗試過(guò)在項(xiàng)目中混用 MyBatis 和 Spring JDBC，你會(huì)發(fā)現(xiàn)割裂感很強(qiáng)：

MyBatis 的TypeHandler在 Spring JDBC 里用不了。

Spring 的RowMapper在 MyBatis 里無(wú)法復(fù)用。

事務(wù)管理器配合往往有坑。

JDBC Template、LambdaQuery、Mapper XML 全部共享同一套TypeHandler 機(jī)制、同一套Session 管理、同一套元數(shù)據(jù)映射。 在 dbVisitor 中，你可以在 Lambda 查詢中復(fù)用 Mapper 定義的 ResultMap，這種底層的一致性是簡(jiǎn)單的拼湊無(wú)法比擬的。

3. 生態(tài)框架的無(wú)關(guān)性

這是 dbVisitor 區(qū)別于 Spring Data 或 MyBatis-Plus 的另一個(gè)重要特征。 dbVisitor 的核心不依賴 Spring，也不依賴任何 Web 容器。它基于純 Java (JDK 8+) 和 JDBC 標(biāo)準(zhǔn)構(gòu)建。 這意味著：

• 你可以在Spring Boot中用它。

• 你可以在Solon、Vert.x、Quarkus中用它。

你甚至可以在一個(gè)沒(méi)有任何依賴的 Main 方法控制臺(tái)程序中直接 new 出來(lái)使用它。

這種零耦合的特性，讓它不僅能適應(yīng)現(xiàn)有的各種技術(shù)棧，更能在未來(lái)的架構(gòu)演進(jìn)中保持生命力，不會(huì)被綁定在某個(gè)特定框架的戰(zhàn)車上。

結(jié)語(yǔ)

物理學(xué)告訴我們要敬畏差異，但軟件工程告訴我們要通過(guò)抽象來(lái)管理復(fù)雜。

dbVisitor 并不試圖用“大一統(tǒng)”去掩蓋數(shù)據(jù)庫(kù)的特性，而是通過(guò)提供一個(gè)統(tǒng)一的基座（JDBC Driver）和分層的 API 設(shè)計(jì)，讓開(kāi)發(fā)者在簡(jiǎn)單場(chǎng)景享受“大一統(tǒng)”的便利，在復(fù)雜場(chǎng)景擁有“原生級(jí)”的掌控。這就是 dbVisitor 敢于挑戰(zhàn)數(shù)據(jù)訪問(wèn)“大一統(tǒng)”的底氣。

- 項(xiàng)目首頁(yè)：https://www.dbvisitor.net/
- 項(xiàng)目源碼：https://gitee.com/zycgit/dbvisitor

如果你對(duì)這個(gè)項(xiàng)目非常感興趣不妨 “加個(gè)關(guān)注” 及對(duì)我支持一下。