关于 DSL 驱动后台页面的设计与实践

做管理后台时，表格、搜索、新增和编辑页面经常反复出现。业务字段不一样，页面结构却很相似：每做一个模块，都要重新写一遍表单、列表和按钮。

整理这个问题时，我尝试用一套 DSL（领域特定语言）来描述后台页面：把菜单、字段、控件和操作写成配置，再交给页面组件解析。这里的 DSL 不是发明一门编程语言，而是给后台页面约定一套面向业务的配置方式。

从页面结构开始

一个常见的后台页面可以拆成几部分：头部菜单、侧边栏，以及中间的内容区域。内容区域有些是表格和表单，有些是自定义页面，也可能需要嵌入第三方页面。

所以菜单配置里可以区分不同的 moduleType：

{
  key: 'products',
  name: '商品管理',
  menuType: 'module',
  moduleType: 'schema',
  schemaConfig: { /* 表格、搜索和表单配置 */ },
}

schema 适合结构比较统一的列表和表单页面；特殊页面可以使用 custom；需要嵌入其他页面时可以使用 iframe。不是所有业务都要塞进 Schema 页面里。

用字段配置生成页面

以商品名称为例，它可能需要在表格中展示，也可以作为搜索条件，还要出现在新增、编辑表单里。配置可以写在同一个字段下：

const schema = {
  type: 'object',
  properties: {
    name: {
      type: 'string',
      label: '商品名称',
      tableOption: { visible: true },
      searchOption: { comType: 'input', default: '' },
      createFormOption: { comType: 'input', visible: true },
      editFormOption: { comType: 'input', visible: true },
    },
  },
  required: ['name'],
}

表格读取 tableOption 生成列，搜索栏根据 searchOption 生成输入框，新增和编辑表单则读取对应的表单配置。按钮、弹窗和请求地址还需要另外配置，不是光有字段就能完成整个页面。

这里也要区分标准和扩展：type、properties、required 来自 JSON Schema；tableOption 等是页面自己约定的 UI 配置。后端接口仍然需要实现，前端配置不能代替服务端校验。

模型和项目配置

有些后台的菜单结构基本一样，只是项目名称、部分菜单或者页面配置不同。可以先抽出一份通用 model，再让具体 project 在它的基础上调整。

例如通用模型里有「视频管理」和「用户管理」，某个项目可以修改其中一个菜单的名字，再增加「课程资料」菜单。解析时根据 key 处理：两边都有的合并配置，只在项目里出现的新增，只在模型里出现的保留。嵌套菜单也需要按同样的约定处理。

这种方式让相似项目能复用一部分配置，但合并规则一定要写清楚。尤其是数组、默认值和同名字段，不能只看一眼就以为所有情况都符合预期，最好用实际配置覆盖测试。

配置化的边界

这套方式比较适合字段结构和操作流程相近的页面。简单页面可以少写不少重复代码，但如果涉及复杂交互、字段联动或特殊权限，配置也会越来越复杂，这时自定义组件可能更合适。

DSL 最重要的不是把页面上的每个东西都变成配置，而是让常见需求有一套大家看得懂、改得动的约定。哪些地方需要扩展、配置出错时怎么提示，也要一起考虑。