产品优势

减少后端 API 开发

在传统后端开发中，为数据库表编写 CRUD 接口是一项重复但必须的工作。每张表通常需要路由定义、控制器、服务层、数据访问层、参数校验、错误处理和权限判断——这些代码结构高度相似，却要反复编写。数据墙DBW 的设计目标就是把这类标准化工作从手写代码中解放出来。

传统方式 vs 配置驱动

对比维度	传统后端开发	数据墙DBW
新增一张表的 API	编写路由、控制器、Service、DAO、DTO	在配置文件中加一个实体块
增删改查 + 分页筛选	每个操作都要实现	引擎自动生成
接口文档	手动维护或注解生成	自动生成 OpenAPI 与 Swagger
身份认证与权限	在每个接口中分散判断	配置中声明角色与操作映射
字段控制	手写 DTO 或序列化配置	权限配置中声明 include/exclude

具体减少了什么

一个典型的数据 API 项目，接入数据墙DBW 后以下内容不再需要手写：

• 路由注册：实体名称即为 REST 路径，不需要 app.MapGet("/api/books") 这类代码。
• 查询构造：筛选、排序、分页、字段选择由引擎根据请求参数自动生成 SQL。
• CRUD 实现：GET/POST/PUT/PATCH/DELETE 五类标准 HTTP 操作统一由运行时处理。
• 数据格式转换：数据库字段到 API 字段的映射、别名统一在实体配置中声明。
• 接口文档：OpenAPI 规范随配置自动生成，不需要手写注解。
• 分页逻辑：游标分页、nextLink 生成、$first/$after 参数解析全部内置。

数据墙DBW 可以基于同一份实体配置同时生成 REST API 和 GraphQL API，启用 MCP 后还会把数据库能力以工具形式暴露给 AI 代理。配置一次，三种访问方式同时可用。

它的定位不是替代所有后端代码，而是把标准化的数据访问管道交给配置驱动引擎，让开发团队把精力集中在复杂业务流程、领域模型、异步任务和第三方集成上。

统一数据库访问入口

很多系统中，数据库被多种消费者访问：前端应用、后端服务、数据分析工具、内部管理系统、AI 代理。如果每种消费者都用自己的方式连接数据库，很快就会产生访问路径碎片化、权限分散、接口不一致等问题。

数据墙DBW 提供了一个统一的数据库访问网关，所有消费者通过同一入口、同一套权限模型访问数据：

前端应用 ──→ REST API ──┐
后端服务 ──→ REST API ──┤
低代码平台 → REST API ──┤
移动端 ────→ REST API ──┼──→ 数据墙DBW ──→ 数据库
第三方系统 → REST API ──┤
分析工具 ──→ GraphQL ───┤
AI 代理 ───→ MCP ───────┘

多协议，一套配置

不同消费者有不同偏好。前端和移动端习惯 REST，数据分析和灵活查询场景适合 GraphQL，AI 应用需要 MCP 协议。数据墙DBW 在同一份配置上同时驱动三种协议。三种协议共享同一套实体定义、权限规则、字段控制和缓存策略，不会出现 REST、GraphQL、MCP 权限不一致的问题。

多数据源统一暴露

数据墙DBW 可以同时连接多个数据库，通过 data-source-files 将它们统一暴露在同一个 API 入口下。消费者只需记住一个 API 地址，不需要知道背后有多少个数据库、它们是什么类型、分布在哪些服务器上。

统一权限与可观测性

所有数据访问经过同一个网关，权限规则在一处集中定义和执行。同时，所有访问都有统一的日志、追踪和监控，为安全审计、性能分析和数据治理提供了全景视图。

降低接口维护成本

接口开发完成后，真正的成本在长期维护。数据库结构变化、字段增删、权限调整、新增业务表——每次变更都可能需要改代码、测试、部署。数据墙DBW 的配置驱动模式在维护阶段的价值尤为突出。

数据库变更，改配置即可

变更场景	传统做法	数据墙DBW 做法
加一张表	编写完整 CRUD 代码，部署上线	在 entities 中加一个实体块，重启生效
加字段	改 Model、改 DTO、改接口	字段自动出现在 API 响应中
列名重命名	改代码 + 通知所有消费者	加一个字段别名，API 外部名称不变
新增角色权限	在每个接口中改代码	在 permissions 中加一行
调整分页大小	改代码、测试、部署	改 runtime.pagination 值

字段别名：保持 API 接口稳定

数据库列名有时会因为内部规范调整而改变，但外部 API 消费者不应该受此影响。fields.alias 机制让 API 字段名独立于数据库列名：

{
  "fields": [
    { "name": "sku_product_title", "alias": "title" },
    { "name": "sku_internal_code",   "alias": "code" }
  ]
}

对外 API 一直返回 title 和 code，消费者代码无需修改，内部列名调整不会影响任何 API 消费者。

自动实体发现

当业务频繁新增数据库表时，autoentities 允许你按模式匹配自动公开新表。符合命名规则的表会在服务重启后自动成为 API，不需要任何手动配置。

CI/CD 友好

配置文件是纯 JSON 文本，天然适合版本控制和 CI/CD 流程。你可以用 Git 追踪变更历史、为不同环境维护不同分支、通过流水线自动校验配置格式（dab validate）、把配置变更纳入 Code Review 流程。

适合容器化部署

数据墙DBW 以容器镜像形式发布，启动后可直接访问。服务不依赖本地文件系统持久化，所有配置通过 JSON 文件或环境变量注入，这些特性让它天然适合容器化部署和云原生环境。

无状态架构

数据访问请求由引擎直接转发至数据库，服务实例之间无需状态同步。多个实例可以横向扩展、互为副本，任何一个实例重启或替换都不影响其他实例。如需跨实例共享缓存，可接入 Redis 作为二级缓存（L2 Cache）。

三种运行形态

运行方式	命令	适用场景
本地进程	dab start	开发调试、本地测试
容器运行	docker run	测试环境、生产部署
源码构建	dotnet run	定制开发、源码审查

三种方式共享同一份配置文件，本地跑通的配置可以直接用于容器环境。

配置外部化与健康检查

容器化部署的核心需求是配置外部化。数据墙DBW 支持 @env('SQL_CONNECTION_STRING') 语法引用环境变量，配合 Docker 或 Kubernetes 的变量注入机制，同一份配置文件可适配不同环境。敏感信息（如连接字符串）无需写入配置文件，通过环境变量传入即可。

服务内置健康检查端点 GET /health，容器编排平台可直接用它做存活探测和就绪探测。服务启动迅速、资源占用较低，在资源受限环境和大型集群场景中都能良好运转。