songqq
b03b5385a5
重构所有注解@CacheConfig的Service类，将IEntityService泛型从实体类改为VO类 实现实体与VO之间的转换逻辑，使用VO替代实体进行缓存以避免序列化问题 更新相关依赖组件和测试用例，确保功能完整性和系统兼容性 优化Redis缓存配置，清理旧缓存数据并验证新缓存策略有效性
94 lines
5.2 KiB
Markdown
94 lines
5.2 KiB
Markdown
# IEntityService接口泛型修改任务共识文档
|
||
|
||
## 1. 明确的需求描述
|
||
|
||
### 1.1 基础需求
|
||
将server模块中所有注解了@CacheConfig的Service类实现的IEntityService接口的泛型参数从实体类类型修改为对应的VO类类型，并同步修改这些Service类中实现的IEntityService接口的所有方法的参数和返回类型。
|
||
|
||
### 1.2 扩展需求
|
||
使用VO替代实体类进行缓存，避免Hibernate代理对象在Redis序列化过程中可能导致的懒加载异常问题。
|
||
|
||
### 1.3 需求目标
|
||
通过将IEntityService接口的泛型从实体类改为VO类，实现接口层与数据访问层的更好解耦，并提高系统的可维护性。同时，通过使用VO对象作为缓存值，彻底解决Redis缓存中的代理对象序列化问题。
|
||
|
||
## 2. 验收标准
|
||
|
||
1. **功能完整性**: 修改后的Service类能够正确实现IEntityService<Vo>接口的所有方法
|
||
2. **类型一致性**: 所有方法的参数和返回类型与新的泛型参数一致
|
||
3. **缓存功能**: 缓存配置和注解在修改后仍然有效
|
||
4. **数据转换**: 正确处理实体类和VO类之间的数据转换
|
||
5. **系统兼容性**: 修改后不影响系统的其他功能模块
|
||
6. **编译通过**: 修改后的代码能够成功编译，无编译错误
|
||
|
||
## 3. 技术实现方案
|
||
|
||
### 3.1 泛型修改方案
|
||
|
||
对于每个注解了@CacheConfig的Service类：
|
||
|
||
1. **修改接口声明**: 将`implements IEntityService<EntityClass>`修改为`implements IEntityService<VoClass>`
|
||
|
||
2. **修改方法签名**: 同步修改所有实现的IEntityService接口方法的参数和返回类型
|
||
- findById(Integer id): 返回类型从EntityClass改为VoClass
|
||
- findAll(Specification<EntityClass> spec, Pageable pageable): 参数类型和返回类型从EntityClass改为VoClass
|
||
- getSpecification(String searchText): 返回类型从Specification<EntityClass>改为Specification<VoClass>
|
||
- save(T entity): 参数和返回类型从EntityClass改为VoClass
|
||
- delete(T entity): 参数类型从EntityClass改为VoClass
|
||
|
||
### 3.2 数据转换策略
|
||
|
||
1. **实体到VO的转换**:
|
||
- 为每个Service类添加实体类到VO类的转换方法
|
||
- 在findById、findAll等返回VO的方法中，使用转换方法将查询到的实体对象转换为VO对象
|
||
|
||
2. **VO到实体的转换**:
|
||
- 在save、delete等接收VO参数的方法中，先将VO对象转换为实体对象，再调用Repository进行操作
|
||
- 利用现有的VoableService接口提供的updateByVo方法进行属性映射
|
||
|
||
### 3.3 缓存注解处理
|
||
|
||
1. 假设VO类与实体类具有相同的属性结构（如id、code等），因此缓存注解中的键表达式（如@CacheEvict(key = "#p0.id")）可能不需要修改。如果VO类结构不同，需要相应调整缓存键表达式。
|
||
2. 确保所有标注@Cacheable的方法都返回VO对象，并在存储前完成从实体类到VO的转换，以避免代理对象序列化问题
|
||
3. 清除Redis中现有的实体类缓存数据，确保新的缓存数据都是VO对象
|
||
|
||
### 3.4 Specification处理
|
||
|
||
由于Specification是基于JPA实体类的查询规范，需要特别处理getSpecification方法：
|
||
|
||
1. 如果VO类与实体类结构相似，可以保留原有的Specification实现，但需要修改泛型类型
|
||
2. 如果需要基于VO类属性构建查询，可能需要创建新的转换逻辑
|
||
|
||
## 4. 技术约束
|
||
|
||
1. **保持接口兼容性**: 不修改IEntityService接口的定义，只修改实现类
|
||
2. **数据一致性**: 确保实体类和VO类之间的数据转换不会导致数据丢失或不一致
|
||
3. **事务边界**: 确保修改不会破坏原有的事务处理逻辑
|
||
4. **性能影响**: 考虑数据转换可能带来的性能影响，必要时进行优化
|
||
5. **序列化约束**: 确保VO类是可序列化的（实现Serializable接口），避免在VO类中包含不可序列化的引用，确保Redis缓存的序列化和反序列化性能
|
||
|
||
## 5. 集成方案
|
||
|
||
1. **阶段性修改**: 可以按模块或按功能进行阶段性修改，降低风险
|
||
2. **依赖更新**: 同步更新所有调用修改后Service的组件，确保它们使用新的接口定义
|
||
3. **测试策略**: 对修改后的Service类进行单元测试和集成测试，验证功能正确性
|
||
|
||
## 6. 任务边界限制
|
||
|
||
1. **范围限制**: 仅修改server模块中注解了@CacheConfig的Service类
|
||
2. **接口限制**: 不修改IEntityService和VoableService接口的定义
|
||
3. **不涉及功能**: 不添加新功能，仅修改现有功能的实现方式
|
||
|
||
## 7. 关键假设确认
|
||
|
||
1. **VO类结构**: 假设VO类与对应的实体类具有相似的属性结构，特别是缓存键中使用的属性
|
||
2. **转换机制**: 假设系统中存在或可以添加实体类与VO类之间的转换机制
|
||
3. **依赖影响**: 假设修改Service接口不会导致不可预见的依赖问题
|
||
|
||
## 8. 项目特性规范对齐
|
||
|
||
- **代码规范**: 遵循项目现有的Java编码规范和命名约定
|
||
- **文档规范**: 按照6A工作流创建相应的文档
|
||
- **测试规范**: 为修改后的代码编写测试用例，确保功能正确
|
||
- **版本控制**: 所有修改通过版本控制系统管理，便于回溯
|
||
|
||
以上共识内容已经明确了任务的需求、验收标准、技术实现方案和约束条件，为后续的架构设计和实现阶段提供了清晰的指导。 |