数据字典的转换逻辑是什么?是在前端转换,后端 Service 层转换还是在数据库层转换?

数据字典的转换逻辑可以灵活部署在不同层级，具体设计取决于系统需求和架构。以下是三种场景的对比和典型应用案例：

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，存储编码而非名称，进一步验证转换在后端或前端完成。

设计建议

总结

数据字典转换的层级选择取决于：

1. 变更频率：高频变动字段建议后端管理
2. 性能要求：高并发场景优先前端或缓存
3. 系统复杂度：多端协作系统推荐后端统一处理
4. 开发资源：小团队可优先前端实现

你的系统当前采用 后端 Service 层转换，是兼顾灵活性和维护性的合理方案。