数据字典的转换逻辑可以灵活部署在不同层级，具体设计取决于系统需求和架构。以下是三种场景的对比和典型应用案例：
1. 前端转换（适合轻量级应用）
场景：
• 字段选项固定且不频繁变动（如性别、学历）
• 需要快速实现，无需后端配合
• 移动端或静态页面应用
案例：
• 维修类型字段在前端维护映射关系：
const repairTypeMap = {'1': '安装单', '2': '维修单','3': '验机&抄配置'
};
// 渲染时直接转换
displayText = repairTypeMap[backendData.repairType];
优点：
• 减轻后端压力，响应更快
• 灵活调整显示名称（如“维修单”改为“设备维修”）
缺点：
• 字典变更需发版前端
• 多端需同步维护映射表
2. 后端 Service 层转换（推荐方案）
场景：
• 字段与业务强关联（如工单状态、服务类型）
• 需要动态权限控制（如不同角色看到不同字典项）
• 系统复杂度较高，需统一管理
案例（见你提供的代码）：
// 1. 查询字典表生成映射
Map<String, String> repairTypeMap = dictService.getDictMap("REPAIR_TYPE");// 2. 转换编码为名称
hpbnVos.forEach(vo -> vo.setRepairType(repairTypeMap.get(vo.getRepairType())));
优点：
• 逻辑集中，易维护
• 支持动态过滤（如停用某些字典项）
• 多端一致性（App/PC端共用同一逻辑）
缺点：
• 增加后端负载
• 需设计字典表查询缓存
3. 数据库层转换（适合报表类系统）
场景：
• 实时性要求低
• 需要复杂 SQL 统计（如跨表联查）
• 数据库性能足够
案例：
SELECT h.order_no,(SELECT name FROM var_dict WHERE type='REPAIR_TYPE' AND code=h.repair_type) AS repair_type_name
FROM h3bn h;
优点：
• 简化业务层逻辑
• 直接输出可读结果
缺点：
• SQL 复杂度高
• 联查可能拖慢性能
结合图片的典型设计解析
第一张图片（工单列表）
• 前端显示：“维修类型”显示为“安装单”、“维修单”，但数据库存储编码（如 1, 2）。
• 实现方式：通过你提供的 CsHpOrH3hOrderServiceImpl 代码，后端 Service 层从字典表查询映射关系，遍历替换字段值。
第二张图片（开发环境）
• SQL 直接查编码：SQL 中未关联字典表，说明转换逻辑未在数据库层实现。
• 右侧面板：数据库表结构显示 repair_type 字段为 varchar，存储编码而非名称，进一步验证转换在后端或前端完成。
设计建议
| 场景 | 推荐方案 | 理由 |
|---|---|---|
| 业务系统（如工单管理） | 后端 Service 层转换 | 集中控制权限、支持动态更新字典、避免 SQL 复杂度 |
| 数据看板/报表 | 数据库层转换 | 直接输出可读结果，简化 BI 工具取数逻辑 |
| 轻量级移动端应用 | 前端转换 | 减少接口交互，提升响应速度 |
总结
数据字典转换的层级选择取决于：
- 变更频率：高频变动字段建议后端管理
- 性能要求：高并发场景优先前端或缓存
- 系统复杂度：多端协作系统推荐后端统一处理
- 开发资源：小团队可优先前端实现
你的系统当前采用 后端 Service 层转换，是兼顾灵活性和维护性的合理方案。
