AI MCP Gateway 从消息处理案例到 DAO 数据层落地

一、这一节做了什么

3.6 分支是在 3.5 分支的基础上继续向前推进的一步。

如果说 3.5 还停留在“消息协议处理案例”的阶段，那么 3.6 做的核心事情，就是把项目的基础设施层数据能力补齐，正式引入了：

  • MyBatis 持久层映射
  • DAO 接口定义
  • PO 数据对象
  • MCP 网关相关库表设计
  • CRUD 测试验证

这一节的主题可以概括为：

从“协议消息怎么处理”，推进到“这些协议配置和网关信息如何落库、如何查询、如何维护”。

二、3.6 比 3.5 多了什么

3.6 分支相对 3.5 主要新增了 1 个提交：

  • feat: 第3-6节：基础层数据处理(Dao)

从改动内容看，重点不是业务逻辑编排，而是数据层正式建模。

1. 新增了 4 组核心 DAO 接口

这一节新增了 4 个 DAO 接口，分别负责 4 张核心业务表的持久化操作：

  • IMcpGatewayDao
  • IMcpGatewayAuthDao
  • IMcpProtocolRegistryDao
  • IMcpProtocolMappingDao

每个 DAO 都提供了统一的基础 CRUD 能力：

  • insert
  • deleteById
  • updateById
  • queryById
  • queryAll

也就是说，到了 3.6，项目已经不再只是定义消息结构，而是具备了真正访问数据库的能力。

2. 新增了 4 组 PO 对象

为了配合 DAO 和 MyBatis 映射，这一节还新增了对应的 PO 对象：

  • McpGatewayPO
  • McpGatewayAuthPO
  • McpProtocolRegistryPO
  • McpProtocolMappingPO

这些对象的作用，是把数据库表结构映射成 Java 中的领域外数据承载对象，方便：

  • 数据库存取
  • Mapper 映射
  • 测试构造
  • 后续仓储层或领域层转换

这一步是典型的基础设施层建设。

3. 新增了 4 份 MyBatis Mapper XML

除了 Java 接口和 PO，这一节还补上了对应的 MyBatis XML 映射文件：

  • mcp_gateway_mapper.xml
  • mcp_gateway_auth_mapper.xml
  • mcp_protocol_registry_mapper.xml
  • mcp_protocol_mapping_mapper.xml

这些 XML 文件的作用是：

  • 定义表字段和 PO 属性之间的映射关系
  • 编写具体 SQL
  • 实现基础增删改查

这说明 3.6 已经从“接口定义”走到了“SQL 可执行”的阶段。

4. 正式切换到 MCP 网关业务库表

3.5 之前，项目里还有较明显的示例工程痕迹，比如：

  • 使用旧示例库 xfg_frame_archetype
  • 存在旧的 frame_case_mapper.xml
  • 配套 SQL 也是示例数据结构

到了 3.6，这些都被替换为正式的 MCP 网关业务模型：

  • 数据库切换为 ai_mcp_gateway
  • 删除旧案例 Mapper
  • 新增正式 SQL 脚本 ai_mcp_gateway.sql

这说明项目从“演示性质的数据结构”切换到了“面向 MCP Gateway 的正式数据结构”。

5. 开启 MyBatis 配置

在 application-dev.yml 中，这一节做了两件很关键的事情：

  • 数据源从旧库切换到 ai_mcp_gateway
  • 开启 MyBatis 配置项

也就是说，从这一步开始，项目本地运行时已经能真正加载 MyBatis Mapper，并与正式数据库打通。

6. 增加了完整的 DAO 测试

这一节还新增了 4 组 DAO 测试类，覆盖了典型数据操作场景，例如：

  • 插入数据
  • 根据 ID 查询
  • 查询全部
  • 更新数据
  • 删除数据
  • 校验 SQL 初始化数据是否可读

这一步很重要，因为它意味着：

3.6 不是只把接口和 XML 写出来，而是已经通过测试把整个数据链路验证了一遍。

三、这 4 张表分别是干什么的

为了理解这一节的价值，需要先理解这 4 张表在整个 MCP Gateway 里的职责。

1. mcp_gateway：网关基础信息表

这一张表保存的是网关本身的信息，比如：

  • 网关唯一标识
  • 网关名称
  • 网关描述
  • 启用/禁用状态

它解决的问题是：

系统里有哪些网关，每个网关是什么，当前是否启用。

2. mcp_gateway_auth：网关鉴权配置表

这张表用于保存某个网关的访问控制信息，例如：

  • api_key
  • 速率限制
  • 过期时间
  • 状态

它解决的问题是：

调用这个网关是否需要鉴权，凭证是什么，访问有没有限制。

3. mcp_protocol_registry：MCP 工具注册表

这张表可以理解为“工具目录”或“协议注册中心”，保存的是：

  • 属于哪个网关
  • 工具 ID
  • 工具名称
  • 工具描述
  • HTTP 地址
  • 请求方法
  • 请求头
  • 超时时间
  • 重试次数

它解决的问题是：

某个 MCP 工具最终要映射到哪个 HTTP 接口，以及调用它需要什么基础配置。

4. mcp_protocol_mapping：协议字段映射表

这是最关键的一张配置表之一，用来保存 MCP 协议字段与 HTTP 请求/响应字段之间的映射关系，例如：

  • 是请求映射还是响应映射
  • 字段的层级结构
  • MCP 路径
  • HTTP 路径
  • 字段类型
  • 是否必填
  • 参数位置（body/query/path/header）

它解决的问题是：

MCP 工具协议里的字段，最终应该如何组装成 HTTP 请求，以及 HTTP 返回结果又应该如何反向映射回 MCP 协议结构。

四、这一节的核心流程是什么

这一节真正建立起来的流程，可以概括为下面这条链路：

1. 先设计业务表结构

首先，要明确 MCP Gateway 运行时到底需要哪些持久化信息。

于是项目把数据拆成 4 类：

  • 网关基础信息
  • 网关鉴权配置
  • 工具注册信息
  • 协议字段映射信息

这一步的本质是：

先把“运行一个网关到底需要保存什么信息”定义清楚。

2. 根据表结构定义 PO 对象

数据库表有了之后，Java 侧需要能承接这些数据，所以新增了对应的 PO 类。

例如：

  • 一条网关记录，对应一个 McpGatewayPO
  • 一条工具注册记录，对应一个 McpProtocolRegistryPO

这一步的作用是：

让数据库记录可以在 Java 代码中以对象方式流转。

3. 定义 DAO 接口，抽象数据访问能力

接下来，为每张表定义 DAO 接口，把数据访问动作抽象出来。

例如：

  • 插入网关配置
  • 查询某个工具注册信息
  • 更新某条映射规则
  • 删除某个鉴权配置

这一步的意义在于：

上层业务不需要关心 SQL 细节，只需要通过 DAO 获取和维护数据。

4. 用 MyBatis Mapper XML 把 DAO 和 SQL 连接起来

DAO 只是接口，真正执行 SQL 的是 MyBatis Mapper XML。

Mapper 负责完成两件事：

  • 把数据库字段映射到 PO 属性
  • 把 DAO 方法映射到具体 SQL

这样之后，一次查询链路就打通了：

  • 业务调用 DAO
  • DAO 对应到 Mapper XML
  • Mapper 执行 SQL
  • SQL 查询结果映射回 PO

5. 配置数据源与 MyBatis 运行环境

为了让这些 DAO 真正跑起来，还需要：

  • 指向正确数据库
  • 开启 MyBatis Mapper 扫描
  • 加载 MyBatis 配置文件

因此 application-dev.yml 也完成了相应切换。

这一步完成后，项目已经具备本地联调数据库的能力。

6. 通过 DAO 测试验证整条链路可用

最后再通过测试完成验证：

  • 插入是否成功
  • 主键是否正确回填
  • 查询是否能读出数据
  • 更新是否生效
  • 删除是否可用
  • 初始化 SQL 的样例数据是否能查到

这一步的意义是：

把“设计完成”变成“可运行、可验证、可继续迭代”。

五、如果站在整个项目演进上，3.6 处于什么位置

从项目演进角度看，3.6 是非常关键的一步，因为它完成了从“协议处理案例”到“可落地数据基础设施”的过渡。

在它之前，项目更偏向：

  • 会话管理
  • SSE 接口
  • MCP 消息结构
  • 消息处理案例

而从 3.6 开始，项目进入了一个更工程化的阶段：

  • 有正式库表
  • 有正式 DAO
  • 有正式 Mapper
  • 有正式测试
  • 后续的协议注册、字段映射、鉴权、网关配置，都可以建立在这套数据底座之上

可以说：

3.6 不是直接增强了 MCP 协议处理能力，而是为后续所有网关配置化能力打下了数据基础。

六、这一节的价值总结

这一节最大的价值，不在于增加了多少业务功能，而在于它让项目具备了“配置可持久化”的能力。

总结下来，3.6 主要完成了三件事：

  • 把 MCP Gateway 的核心配置抽象成正式库表
  • 用 DAO + MyBatis 建立了完整的数据访问能力
  • 用测试验证了数据链路真实可用

这意味着后面的系统能力，不再只能写死在代码里，而是可以逐步走向：

  • 配置化
  • 持久化
  • 可维护
  • 可扩展

这正是一个网关系统从 Demo 走向工程化实现的重要一步。

七、一句话总结

3.6 分支相比 3.5，核心不是新增消息协议能力，而是补齐了 MCP Gateway 的 DAO 数据层、MyBatis 映射和正式库表设计，为后续网关注册、协议映射、鉴权与配置管理提供了持久化基础。