应用场景

快速发布数据库接口

将现有数据库快速转化为标准化的 REST 和 GraphQL API，无需从零编写 CRUD 代码。数据墙DBW 通过配置驱动的方式，让你几分钟内即可发布可用的数据接口。

典型流程

假设你有一个现有数据库，包含多张业务表。现在需要给新上线的管理系统提供数据接口。传统做法需要搭建项目、写 Model/Controller/Service、实现分页筛选、配置权限、写文档。接入数据墙DBW 后：

1. 安装 CLI：dotnet tool install -g dab
2. 初始化配置：dab init 连接数据库
3. 添加实体：dab add Book --source dbo.books --permissions "anonymous:read"
4. 启动服务：dab start

几分钟后 GET /api/Book 即可用。同一个实体配置同时生成 REST 端点和 GraphQL 查询，启用 MCP 后还会向 AI 代理暴露数据工具。

为什么适合

• 数据库不需要改动：只读取已有的表、视图和存储过程。
• 一次配置，多协议可用：REST、GraphQL、MCP 共享同一份实体模型。
• 权限可控：未配置的表在 API 层面完全不可见。
• 可与现有系统并存：作为独立进程运行，不影响已有的后端服务。

常见案例包括遗留系统改造、临时数据需求、原型快速验证。

面向第三方合作伙伴的数据开放

企业对外提供数据接口时，安全边界和权限隔离是首要考量。数据墙DBW 通过配置化的权限模型，可以为不同合作伙伴定义独立的访问范围：

合作伙伴 A ──→ JWT 身份 ──→ 角色 A ──→ 指定实体只读 ──→ 数据墙DBW ──→ 数据库
合作伙伴 B ──→ JWT 身份 ──→ 角色 B ──→ 指定实体读写 ──→ 数据墙DBW ──→ 数据库

• 角色隔离：每个合作伙伴分配独立角色，权限精确到实体和操作级别。
• 字段级控制：同一张表，不同合作伙伴看到的字段可以不同，敏感列直接排除。
• 行级过滤：通过数据访问策略，限制合作伙伴只能访问与其业务相关的数据行。
• 统一审计：所有外部访问经过同一网关，日志集中可查，便于合规审计。

对外数据开放时，建议配合反向代理或 API 网关使用，在数据墙DBW 前面增加限流、IP 白名单、HTTPS 终止等安全层。

为前端和低代码平台提供数据接口

前端应用和低代码平台对后端接口的需求非常明确：标准 REST API、一致响应格式、筛选排序分页、接口文档。这些恰好是数据墙DBW 最擅长的部分。

前端开发的数据层

前端开发者经常面临后端接口还没写好、或接口格式不统一的困境。数据墙DBW 可以直接放在数据库前面，给前端一个即开即用的数据 API：

前端应用 ──→ REST API ──┐
                       ├──→ 数据墙DBW ──→ 数据库
低代码平台 → REST API ──┘

标准的 $filter、$orderby、$first、$select 参数让前端灵活地按需获取数据，不需要后端为每种查询组合单独写接口。

低代码平台的天然搭档

低代码平台通常通过 REST API 连接外部数据源。数据墙DBW 的标准 REST 接口和自动生成的 OpenAPI 规范，让低代码平台可以直接导入数据源配置。所有 REST 端点返回统一的 JSON 结构，前端可以封装一个通用 HTTP 客户端处理所有数据墙DBW API 调用。

字段别名：前后端解耦

数据库列名可能不符合前端命名规范。通过字段别名，给前端一个干净的 API——sku_product_title 对外显示为 title。数据库内部命名风格不影响前端代码，将来列名调整只需改配置。

企业内部系统数据封装

中大型企业内部通常有多个业务系统，各自独立。当需要跨系统共享数据时，常见做法是各团队各自暴露接口——风格不统一、权限标准不一致、文档缺失。数据墙DBW 提供了一种统一的企业数据封装方案。

把数据库变成可治理的数据服务

企业可以建立一套数据 API 发布规范：统一使用数据墙DBW 作为数据库对外访问网关，接口通过配置文件定义，权限集中在配置中管理，所有访问有统一日志追踪。IT 团队不再需要为每个数据需求单独开发接口。

多系统数据整合

数据墙DBW 可以同时连接多个数据源，通过 data-source-files 在同一个 API 入口下统一暴露。调用方通过同一入口访问不同数据源，引擎根据实体定义路由到对应数据库。对于需要从多个系统分别取数据的场景，统一入口大幅简化了客户端逻辑。

权限治理

企业内部的数据安全要求通常比公网系统更严格。数据墙DBW 的 RBAC 体系（基于角色的访问控制）天然适合：

• 按组织架构定义角色，配置实体权限和行级过滤。
• 区域经理只能看本区域数据，审核员只能看阈值内的订单。
• 所有访问通过一个网关，日志集中可查，权限变更经过 Code Review。

遗留系统集成

很多老系统技术栈老旧，改造困难。数据墙DBW 可以不改动老系统本身，只把它的数据库通过标准 API 暴露出来，让新系统访问老系统的数据——这是企业内部系统现代化过渡的常见模式。

统一数据服务平台

企业建设统一数据服务平台时，核心诉求之一是让各类数据以标准化、可治理的方式对外提供服务。数据墙DBW 可以作为平台的 API 网关层，将底层数据库快速转化为可管理的数据 API。

统一 API 网关

统一数据服务平台通常汇聚多个业务系统的数据，调用方需要统一入口。数据墙DBW 通过多数据源配置，将不同数据库的表、视图、存储过程统一暴露在同一 API 地址下：

业务系统 A 数据库 ──┐
业务系统 B 数据库 ──┼──→ 数据墙DBW ──→ 统一 REST / GraphQL API ──→ 调用方
主数据平台 ────────┘

调用方无需关心数据来自哪个数据库、哪种类型，只需通过统一的实体名称和数据协议访问。

数据服务治理

统一数据服务平台需要管理大量数据 API 的定义、权限和变更。数据墙DBW 用配置文件来定义所有接口，便于统一管理和审计：

• 配置即文档：配置文件本身就是数据服务的定义文档，实体名称、字段别名、权限规则一目了然。
• 版本控制：配置文件纳入 Git 管理，每次变更可追溯、可回滚、可 Code Review。
• 环境隔离：同一份配置通过环境变量适配开发、测试、生产环境，避免配置漂移。
• 统一观测：所有数据访问经过同一网关，日志、链路追踪、健康检查集中可查。

与现有数据架构并存

数据墙DBW 不是替代已有的数据处理体系，而是作为数据架构中的 API 暴露层。它可以与现有的数据处理流程并存：

• 对实时性要求高的数据，直接通过数据墙DBW 暴露源数据库 API。
• 对经过加工处理的数据库，同样可以通过数据墙DBW 提供查询接口。
• 数据服务目录可以引用数据墙DBW 自动生成的 OpenAPI 规范。

AI 代理访问数据库

随着 AI 代理在企业应用中普及，一个核心问题浮现：如何让 AI 安全地访问数据库？直接给数据库连接权限风险太大。数据墙DBW 通过 MCP 协议提供了一种安全的中间方案。

不是让 AI 写 SQL，而是给它工具

很多方案让 AI 直接生成 SQL 语句（NL2SQL），但模型不是确定性的，复杂查询容易出错。数据墙DBW 采用不同策略：

AI 代理 ──→ MCP 协议 ──→ 数据墙DBW 工具层 ──→ 确定性 SQL ──→ 数据库

代理调用类型化的工具（read_records），引擎负责生成正确的查询。代理不需要知道表结构或 SQL 语法，调用 describe_entities 就能了解有哪些数据和字段。

七个内置工具

工具	用途
describe_entities	了解可访问的实体及其字段
read_records	查询数据，支持筛选排序分页
create_record	创建新记录
update_record	更新已有记录
delete_record	删除记录
execute_entity	调用存储过程
aggregate_records	执行聚合统计查询

安全边界完整

可以为 AI 代理创建专门的受限角色——只给 read 不给 delete。敏感字段在配置中排除，AI 代理感知不到。行级策略限制 AI 代理只能看到被授权的数据。AI 代理不能执行 DDL 或原始 SQL。某个表只想给 REST 客户端用、不给 AI 代理看——不在该实体的 MCP 权限中配置 AI 代理角色即可。

自定义工具与语义描述

存储过程可以注册为命名 MCP 工具，AI 代理按名称直接调用。为实体和字段添加 description 有助于 AI 代理理解数据含义——描述越清晰，AI 代理表现越准确。

典型场景包括企业智能助手、自然语言数据分析、自动化运维巡检、内部知识查询等。