3 篇博文 含有标签「架构」

dbVisitor 是一个旨在提供统一数据库访问体验的 Java 工具库。随着对 MySQL、PostgreSQL 等关系型数据库以及 MongoDB、ElasticSearch 等 NoSQL 数据源支持的不断深入，底层的方言系统（Dialect System）面临着越来越复杂的挑战。

近期，我们对 dbVisitor 的方言系统进行了一次深度的架构重构。本次重构不涉及功能变更，旨在解决旧架构中存在的抽象割裂问题，将“方言元数据”与“命令构建能力”高度内聚。

本文将深入探讨这次架构演进背后的思考、实施方案以及带来的显著优势。

本文将深入解析 dbVisitor 独特的"双层适配"架构，揭示其如何通过应用层与协议层的双重抽象，打破 RDBMS 与 NoSQL 的壁垒。

摘要​

在使用 Java 进行现代应用开发时，混合使用关系型数据库（如 MySQL、PostgreSQL）和非关系型数据库（如 MongoDB、Elasticsearch）已成为常态。 然而，这种混合架构往往导致技术栈割裂：开发者需要在 JDBC/MyBatis 和各种 NoSQL 专有客户端之间频繁切换。

dbVisitor 提出的"双层适配"架构旨在解决这一痛点。

• 第一层（应用适配）：在 API 层面，通过统一的 LambdaTemplate 和 Mapper 接口屏蔽底层语法差异（SQL vs DSL）。
• 第二层（协议适配）：在驱动层面，实现了标准的 JDBC 接口，将 NoSQL 数据源封装为标准 JDBC 驱动。

这种设计不仅实现了"One API Access Any DataBase"的愿景，还带来了极高的灵活性：开发者既可以享受 dbVisitor 全栈的便捷，也可以仅使用其 JDBC 驱动，让现有的 MyBatis/Hibernate 项目瞬间具备操作 NoSQL 的能力。

有开发者引用物理学隐喻：“粒子的位置与动量不可同时确定”，暗示在框架设计中，通用性与专用性难以兼得。 更有人直言，任何尝试“大一统”的框架，最终都会沦为“四不像”，不仅丢掉了数据库的强事务优势，也没能发挥出例如 Elasticsearch 的能力。

面对这些质疑，dbVisitor 依然坚定地提出了 "One API Access Any DataBase" 的愿景。 为什么我敢这么说？今天我们就来拆解这个争议，聊聊 dbVisitor 敢于挑战“大一统”的底气究竟在哪里。