# TODO - Server模块service缓存调整为Vo对象

## 1. 批量修改其他Service类

按照CompanyFileTypeService的修改模式，批量修改以下Service类：
- CompanyCustomerFileTypeService
- CustomerFileTypeService
- CompanyFileService
- CompanyCustomerFileService

### 操作指引：
1. 对于每个Service类：
   - 调整QueryService接口的泛型参数为对应的Vo类
   - 重构findById方法，返回类型改为对应的Vo类，并添加@Cacheable注解
   - 保留getById方法，用于获取实体对象
   - 让实体类继承Voable接口并实现toVo方法，完成从实体到Vo的转换
   - 确保所有标注@Cacheable注解的方法的返回参数类型不为Model类型，全部调整为Vo类型
   - findAll(JsonNode，Pageable)方法的返回类型调整为Page<Vo>，并使用实体类自带的toVo方法进行转换
   - findAll(Specification，Pageable)方法的返回类型保持为Page<Model>
   - 仅保留一个save(Model)方法，用于保存实体对象
   - **不创建独立的toVo方法**：直接使用实体类自带的`toVo()`方法进行转换

2. 确保每个Service类的修改都符合以下要求：
   - 保持接口兼容性
   - 正确使用缓存注解
   - 实现实体与Vo之间的正确转换

## 2. Redis缓存清理

在所有Service类修改完成后，需要清理Redis中的缓存数据，以确保新的缓存策略能够正确生效。

### 操作指引：
1. 开发一个缓存清理工具或脚本
2. 执行缓存清理操作，清除所有相关的缓存键
3. 验证清理结果，确保缓存已被正确清除

## 3. WebSocket服务兼容性处理

检查并确保WebSocket服务能够正确处理Vo对象，避免序列化问题。

### 操作指引：
1. 分析WebSocket服务的代码
2. 确保WebSocket服务能够正确序列化和反序列化Vo对象
3. 必要时进行相应的修改

## 4. 测试验证

对所有修改进行全面的测试验证，确保功能正常。

### 操作指引：
1. 编写单元测试和集成测试
2. 执行功能测试，验证各Service类的功能是否正常
3. 执行性能测试，验证缓存策略的效果
4. 记录测试结果

## 5. 文档更新

完成所有修改后，更新相关文档，包括系统架构文档、API文档等。

### 操作指引：
1. 整理所有修改内容
2. 更新系统架构文档
3. 更新API文档
4. 更新用户手册

## 6. 部署计划

制定详细的部署计划，确保修改能够顺利上线。

### 操作指引：
1. 确定部署时间窗口
2. 制定回滚策略
3. 准备部署脚本
4. 通知相关人员

## 7. 上线后监控

上线后进行持续监控，确保系统运行稳定。

### 操作指引：
1. 设置监控指标
2. 配置告警机制
3. 定期检查系统运行状态
4. 及时处理异常情况