2.9 KiB
2.9 KiB
Context
当前系统无字典管理功能。多个模块（组织管理、站点管理、角色管理等）依赖字典编码进行状态/分类映射（如 zzlbbm、bmzt、zdlx、zdywfw）。数据库表 sys_dict_type 和 sys_dict_data 已在 DDL 中定义，但后端无对应模型、CRUD、API 路由，前端无对应页面。
现有代码模式参考：
- 后端：
crud/tenant.py的独立函数模式（list_*, get_*, create_*, update_*, soft_delete_*），api/admin.py的路由模式 - 前端：
views/system/unit/index.vue标准列表模板，api/admin.ts的request.get/post/put/del模式 - 模型：
models.py中直接使用from app.core.database import Base，公共字段顺序遵循 V0.3 约定
Goals / Non-Goals
Goals:
- 提供字典类型的完整 CRUD（分页列表、新增、修改、软删除）
- 提供字典数据的完整 CRUD（按字典类型分组，支持新增、修改、软删除）
- 前端字典类型列表页 + 字典数据配置弹窗
- 严格遵循租户隔离、软删除、默认排序等工程规范
- 初始化字典数据脚本（zzlbbm、bmzt、zdlx、zdywfw）
Non-Goals:
- 字典缓存机制（后续优化）
- 字典数据批量导入导出
- 字典变更审计日志
- 小程序端字典管理
Decisions
D1: 后端 CRUD 采用独立函数模式（非 CRUDBase 泛型）
选择: 参照 crud/tenant.py 的独立函数 + _row_to_dict() 模式
理由: 现有业务模块（tenant）均使用此模式，保持一致性比引入新模式更重要
替代方案: 使用 crud/base.py 的 CRUDBase[Model] 泛型 → 被弃用，因为 tenant 模块未使用，且手动函数更灵活
D2: 字典 API 路由注册在 admin.py
选择: 在现有 api/admin.py 中新增字典路由组
理由: 字典属于系统管理范畴，与 tenant 同属 admin 路由前缀 /web/admin。模块较少，无需新建文件
替代方案: 新建 api/system.py → 可行但当前系统管理模块可集中管理
D3: 字典数据查询通过 dict_type 关联
选择: 字典数据列表按 dict_type 过滤查询，前端弹窗传入 dict_type 获取对应字典数据
理由: 需求文档明确"点击字典数据配置按钮弹出弹窗"，弹窗需知道当前字典类型
D4: 前端字典数据配置弹窗采用 Dialog + 内嵌表格
选择: 字典类型列表页 + 点击"字典数据配置"弹出 Dialog，Dialog 内展示该类型的字典数据表格，支持行内新增/编辑/删除 理由: 需求文档 2.1.2 描述的交互模式
Risks / Trade-offs
- [字典类型编码唯一性] dict_type 在同一 tenant 下需唯一 → 通过数据库唯一索引
uk_dict_type+ 应用层校验双重保障 - [字典数据量] 某些字典类型数据较多 → 弹窗内分页查询，每页 20 条
- [初始化数据] 需要确保系统初始化时有基础字典数据 → 提供独立 SQL 初始化脚本