至于使用者痛点，CRUD 开发的重复与低效

在传统中后台程序中。开发者往往面临以下痛点：

• **代码重复**：每个业务模块都需要编写相同的列表、搜索、按钮等代码，导致维护成本高。
• **项目间不一致**：多租户或多项目环境下同一功能的页面实现方式不同，难以保证统一体验。
• **变更成本高**：字段变动时必须改动 Vue/React 代码，容易出现遗漏或错误。
• **交互规范混乱**：按钮行为、搜索规则等由各团队自行实现，缺乏统一标准。
• **开发周期长**：从需求到上线需要手写大量模板代码，业务人员难还有时验证需求。

一、什么是 DSL 设计

DSL架构是专为解决特定领域问题而设计的语言或配置规范。它通过可配置的菜单与页面描述协议——使用 JSON 配置描述菜单结构、页面类型、表格列定义、搜索表单、按钮行为等。让前端，摆脱 CRUD 重复？" src="/uploads/images/172.jpg"/>

二、为什么要这样设计

主要问题对比

问题	传统方式	DSL 方式
新增 CRUD 页面	写 Vue/React 模板 + 表格 + 搜索 + 按钮，一份 JSON 配置；多项目/多租户需复制代码；同一套代码但不同配置导致不一致性依赖开发者规范。	将页面结构抽离为配置，实现「改配置即改页面」；同一套前端引擎通过不同 model 配置支撑多个业务程序；标准 CRUD 页面零重复代码，减少80%重复工作；所有页面表格/搜索/按钮行为统一由框架控制。

设计目的

1. 配置驱动渲染: 页面结构从代码抽离为配置，“改配置即改页面”。其实，
2. 多项目复用: 同一套前端引擎。 通过不同 model 支撑多个业务程序。
3. 降低开发成本: 标准 CRUD 页面零重复代码，减少80%工作量。
4. 统一交互规范: 所有页面表格、搜索、按钮行为由框架统一控制。

三、设计思路

整体架构分层

┌─────────────────────────────────────────────────────┐
│ DSL 配置层 │
│ model/buiness/model.js model/course/model.js │
│ │
└──────────────────────┬──────────────────────────────┘
│ API 返回
┌──────────────────────▼──────────────────────────────┐
│ 状态管理层 │
│ menuStore projectStore │
│ │
└──────────────────────┬──────────────────────────────┘
│ 驱动
┌──────────────────────▼──────────────────────────────┐
│ 路由引擎层 │
│ entry.dashboard.js │
│ │
└──────────────────────┬──────────────────────────────┘
│ 渲染
┌──────────────────────▼──────────────────────────────┐
│ 视图组件层 │
│ header-view sider-view schema-view │
│ iframe-view todo-view │
│ │
└───────────────────────▲------------------------------------
├组合
▼
通用组件层
├schema-table schema-search-bar
├header-container sider-container
​ 

菜单模型设计

菜单是整个程序的骨架。采用树形结构 + 类型分发

MenuItem├── key // 唯一标识
├── name // 显示名称
├── menuType // group / module
├──
| └── subMenu: MenuItem // 递归子菜单
├──
| └── moduleType // 决定渲染哪种视图
| ├── schema → schemaConfig → 数据表格页
| ├── iframe → iframeConfig → 内嵌页面
| ├── sider → siderConfig → 侧边栏布局
| └── custom → customConfig → 自定义组件
``
menuType区分「目录」和「模块」，moduleType` 决定渲染引擎，每种类型对应一个视图组件。只挂载必要的 config。

Schema 协议设计

Schemas 是 DSL 最复杂的一块，用一份字段定义，多视图复用 - 来降低重复：

properties: {
product_name: {
说到type。'string',// 字段类型
说到label，'商品名称',// 字段标签
tableOptions: { ... },// 表格列专属配置
searchOptions:{ ... } // 搜索表单专属配置
}
}
再看主要思路，

1️⃣ 字段定义统一——一次定义即可。

2️⃣ 视图配置隔离——使用 tableOptions / searchOptions 后缀区分。

3️⃣ 按需提取——buildDtoSchema 抽取仅含 tableOptions 的字段。

路由分发设计

`router.push` 把模块类型映射到对应路由。侧边栏嵌套路由示例：

js /view/dashboard/sider → sider-view ├─ /sider/iframe → iframe-view ├─ /sider/schema → schema-view └─ /sider/todo → todo

侧边栏通过 sider_key query 参数区分左侧选中项和右侧内容。

数据流向设计

js model 配置 ↓ GET /api/getProject?proj_key=xxx menuStore.setMenuList ↓ header-view 渲染顶部菜单 使用者点击菜单项 router.push → 对应视图组件 ↓ useSchema hook 查找当前菜单配置 ↓ buildDtoSchema 提供 'schemaViewData' 给子组件 ↓ 子组件 render ↓ 使用者操作 emit→父组件处理或透传

• 通用事件
' 在内部处理。'
• 业务事件通过 emit 向上报送，由最终使用方处理。不过，

proj_key — 项目标识

`proj_key` 确定当前访问的是哪个业务项目。并保持在整个生命周期中持续透传，从而保证所有操作在正确项目上下文下执行。关键方法示例已在原文给出，可直接参考。'

sider_key — 侧边栏菜单标识

`sider_key` 用于区分侧边栏中的子菜单，并优先用于定位右侧内容。当没有 `sider_key` 时回退到顶级 `key`。'

两个 key 的协作关系

' ' ' '" "

参数	作用域	决定什么	谁消费
proj_key	全局加载哪个项目的菜单配置	dashboard.vue,menuStore
key	顶部菜单当前激活项	header-view。sider-view,schema-view,iframe-view
sider_key	侧边栏当前激活子项	sider-view,子路由中的视图组件

四、设计优势 --- ### 开发效率

• 零代码 CRUD – 新增数据管理页只需写 config，无需 Vue 代码。'
'
• 统一范式 – 所有人按同一协议编写 config，降低沟通成本。'
'
• 快速原型 – 业务人员可直接修改 JSON 验证需求。'

可维护性

• 逻辑与表现解耦 – model 文件只关心结构，UI 在通用组件里实现。'
'
• 高度复用 – schema-table 、schema-search-bar 等可任意重用。'' '

可 性

• 新模块类型轻松添加 – 新枚举+对应 view 即可。''
• 新搜索控件 – 注册至 search.item.config.js 即可 ''
• 权限细粒度 – 在 DSL 增加权限字段即可细化控制。'' ### 架构清晰度
  • ' '
  • ' '
  • ' '

  ---

---