refactor(service): 统一Service缓存为VO对象并优化关联实体处理

重构Service类实现,将QueryService泛型参数调整为VO类型,确保缓存VO对象而非实体。优化关联实体处理逻辑,减少重复代码。修改findById方法返回VO对象,新增getById方法获取实体。更新相关调用点以适配新接口。

调整WebSocket处理、控制器及Service实现,确保数据类型一致性。完善文档记录重构过程及发现的问题。为后续优化提供基础架构支持。
This commit is contained in:
2025-09-29 19:31:51 +08:00
parent 64471b46f8
commit 49413ad473
167 changed files with 6840 additions and 1811 deletions

View File

@@ -1,165 +1,84 @@
# Server模块Service缓存调整为Vo对象待办事项
# TODO - Server模块service缓存调整为Vo对象
## 1. 代码实现阶段待办
## 1. 批量修改其他Service类
### 1.1 缓存策略设计
- [ ] 设计缓存对象转换机制在缓存写入前将实体对象转换为VO对象
- [ ] 确保所有VO类都实现Serializable接口
- [ ] 验证VO对象的序列化安全性避免引用不可序列化对象
- [ ] 设计Redis缓存键命名规范考虑使用命名空间或前缀
- [ ] 实现Redis连接失败时的降级策略
按照CompanyFileTypeService的修改模式批量修改以下Service类
- CompanyCustomerFileTypeService
- CustomerFileTypeService
- CompanyFileService
- CompanyCustomerFileService
### 1.2 试点Service类修改
- [ ] 选择一个典型的Service类如CompanyCustomerFileTypeService进行试点修改
- [ ] Service类继承IEntityService接口泛型类型保持为Model实体类
- [ ] Service类继承QueryService接口泛型类型改为Vo视图对象
- [ ] 逐一修改实现的接口方法,添加数据转换逻辑
- [ ] 验证修改后的代码能够编译通过
- [ ] 编写单元测试验证功能正确性
### 操作指引:
1. 对于每个Service类
- 调整QueryService接口泛型参数为对应的Vo类
- 重构findById方法返回类型改为对应的Vo类并添加@Cacheable注解
- 保留getById方法用于获取实体对象
- 让实体类继承Voable接口并实现toVo方法完成从实体到Vo的转换
- 确保所有标注@Cacheable注解的方法的返回参数类型不为Model类型全部调整为Vo类型
- findAll(JsonNodePageable)方法的返回类型调整为Page<Vo>并使用实体类自带的toVo方法进行转换
- findAll(SpecificationPageable)方法的返回类型保持为Page<Model>
- 仅保留一个save(Model)方法,用于保存实体对象
- **不创建独立的toVo方法**:直接使用实体类自带的`toVo()`方法进行转换
### 1.2 批量Service类修改
- [ ] 制定批量修改计划,按照模块或功能分组
- [ ] 逐一修改每个注解了@CacheConfig的Service类
- [ ] Service类继承IEntityService接口泛型类型保持为Model实体类
- [ ] Service类继承QueryService接口泛型类型修改为Vo视图对象
- [ ] 应用统一的数据转换机制
- [ ] 记录修改过程中的问题和解决方法
- [ ] 执行编译检查确保所有修改正确
2. 确保每个Service类修改都符合以下要求:
- 保持接口兼容性
- 正确使用缓存注解
- 实现实体与Vo之间的正确转换
## 2. 数据转换相关待办
## 2. Redis缓存清理
### 2.1 转换逻辑实现
- [ ] 设计并实现实体类到VO类的转换方法
- [ ] 设计并实现VO类到实体类的转换方法
- [ ] 考虑添加通用的转换工具类
- [ ] 处理空值和异常情况
在所有Service类修改完成后需要清理Redis中的缓存数据以确保新的缓存策略能够正确生效。
### 2.2 Specification处理
- [ ] 研究如何处理getSpecification方法的泛型修改
- [ ] 确定是否需要保留基于实体类的Specification实现
- [ ] 设计可能的解决方案,如创建适配器或转换层
### 操作指引:
1. 开发一个缓存清理工具或脚本
2. 执行缓存清理操作,清除所有相关的缓存键
3. 验证清理结果,确保缓存已被正确清除
## 3. 依赖组件分析和修改
## 3. WebSocket服务兼容性处理
### 3.1 依赖分析
- [ ] 搜索所有调用修改后Service类的组件Controller、其他Service等
- [ ] 分析这些组件如何使用Service类的方法
- [ ] 识别需要修改的依赖组件
- [ ] 特别关注WebSocket服务组件WebSocketServerCallbackManager、WebSocketServerTaskManager
- [ ] 分析WebSocket服务如何通过反射调用IEntityService接口的方法
- [ ] 识别WebSocket服务中依赖IEntityService泛型参数的方法
检查并确保WebSocket服务能够正确处理Vo对象避免序列化问题。
### 3.2 依赖修改
- [ ] 修改受影响的Controller类
- [ ] 修改受影响的其他Service类
- [ ] 验证依赖修改的正确性
- [ ] 处理可能的级联依赖问题
- [ ] 修改WebSocketServerCallbackManager类
- [ ] 更新createNewEntity、findEntityTypeInInterfaces等依赖泛型参数的方法
- [ ] 调整invokerFindByIdMethod、invokerFindAllMethod等反射调用方法
- [ ] 确保能够正确处理VO类型的返回值
- [ ] 修改WebSocketServerTaskManager类
- [ ] 确保任务执行流程能够适应IEntityService接口的泛型变化
- [ ] 调整任务处理逻辑确保能够正确处理VO类型的数据
- [ ] 添加类型安全检查,防止类型转换错误
- [ ] 验证WebSocket服务组件修改的正确性
### 操作指引:
1. 分析WebSocket服务的代码
2. 确保WebSocket服务能够正确序列化和反序列化Vo对象
3. 必要时进行相应的修改
## 4. 测试验证待办
## 4. 测试验证
### 4.1 测试用例编写
- [ ] 为每个修改后的Service类编写单元测试
- [ ] 编写集成测试验证Service类与其他组件的交互
- [ ] 测试数据转换的正确性和性能
- [ ] 编写缓存功能专项测试用例
- 验证Redis中只存储VO对象不存储实体对象
- 测试VO对象的序列化和反序列化正确性
- 测试Redis连接失败时的降级功能
- 测试缓存清理后的系统运行状态
- [ ] 编写WebSocket服务专项测试用例
- 测试WebSocketServerCallbackManager的类型处理逻辑
- 验证createNewEntity、invokerFindByIdMethod等方法能够正确处理VO类型
- 测试WebSocketServerTaskManager的任务执行流程
- 验证WebSocket服务的整体功能
对所有修改进行全面的测试验证,确保功能正常。
### 4.2 测试执行和问题修复
### 操作指引:
1. 编写单元测试和集成测试
2. 执行功能测试验证各Service类的功能是否正常
3. 执行性能测试,验证缓存策略的效果
4. 记录测试结果
### 4.2 测试执行和问题修复
- [ ] 执行所有测试用例
- [ ] 分析测试结果,记录发现的问题
- [ ] 修复测试中发现的问题
- [ ] 重新执行测试,确保所有问题都已解决
## 5. 文档更新
## 5. 配置和部署相关待办
完成所有修改后更新相关文档包括系统架构文档、API文档等。
### 5.1 Redis缓存清理
- [ ] 制定Redis缓存清理计划
- [ ] 编写脚本查找并删除所有旧的实体类缓存
- [ ] 确保在新代码部署前完成缓存清理
- [ ] 验证清理效果,确保没有旧缓存残留
### 操作指引:
1. 整理所有修改内容
2. 更新系统架构文档
3. 更新API文档
4. 更新用户手册
### 5.2 缓存配置检查
- [ ] 验证缓存配置在修改后仍然有效
- [ ] 检查缓存键表达式是否需要调整
- [ ] 测试缓存的读写和失效机制确保只使用VO对象
## 6. 部署计划
### 5.2 部署准备
- [ ] 准备部署文档,说明修改内容和注意事项
- [ ] 考虑分阶段部署策略,降低风险
- [ ] 准备回滚方案,以防出现严重问题
制定详细的部署计划,确保修改能够顺利上线。
## 6. 文档更新待办
### 操作指引:
1. 确定部署时间窗口
2. 制定回滚策略
3. 准备部署脚本
4. 通知相关人员
### 6.1 代码文档更新
- [ ] 为修改后的Service类添加JavaDoc注释
- [ ] 更新相关接口和类的文档
- [ ] 确保文档与代码的一致性
## 7. 上线后监控
### 6.2 项目文档更新
- [ ] 更新ACCEPTANCE文档记录测试结果和完成情况
- [ ] 更新FINAL文档添加实际执行结果
- [ ] 归档所有任务文档
上线后进行持续监控,确保系统运行稳定。
## 7. 其他待办事项
### 7.1 缓存管理机制建立
- [ ] 建立缓存键命名规范文档
- [ ] 定义缓存过期策略
- [ ] 设置Redis监控措施定期检查缓存状态
- [ ] 建立缓存清理和刷新的标准流程
### 7.2 性能优化
- [ ] 分析数据转换可能带来的性能影响
- [ ] 考虑添加转换结果缓存或其他优化手段
- [ ] 进行性能测试,确保修改不会导致性能退化
### 7.2 知识分享
- [ ] 组织团队成员进行知识分享,介绍修改内容和技术方案
- [ ] 记录经验教训,为后续类似任务提供参考
- [ ] 考虑是否需要更新项目开发规范
## 8. 支持需求
以下是在实施过程中可能需要的支持:
### 8.1 技术支持
- [ ] 数据转换框架选择和实现建议
- [ ] Specification泛型修改的最佳实践
- [ ] 缓存配置优化建议
- [ ] Redis缓存管理和序列化最佳实践
- [ ] 分布式缓存问题排查和解决支持
### 8.2 资源支持
- [ ] 代码审查资源
- [ ] 测试环境和测试数据准备
- [ ] 部署和监控资源
### 8.3 其他支持
- [ ] 与相关团队的协调和沟通
- [ ] 变更管理和审批流程支持
- [ ] 风险评估和缓解策略建议
---
**更新记录**:
- 创建日期: -
- 更新日期: -
- 更新内容: -
### 操作指引:
1. 设置监控指标
2. 配置告警机制
3. 定期检查系统运行状态
4. 及时处理异常情况