songqq/contract-manager
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects 1 Releases 1 Wiki Activity
Files
1f354853b0c2b544da48fd5ffad14b6ec17c1fd6
contract-manager/docs/task/server模块service缓存调整为Vo对象/ALIGNMENT_server模块service缓存调整为Vo对象.md
songqq 1f354853b0 refactor(service): 调整接口泛型参数并优化缓存策略 
docs(task): 更新接口泛型修改相关文档

- 重构QueryService接口，移除未使用的Specification相关方法
- InventoryCatalogService实现IEntityService和QueryService接口
- 新增delete方法实现并调整缓存配置
- 删除过时的任务文档并重新组织文档结构
- 更新ALIGNMENT、CONSENSUS等文档，添加WebSocket服务兼容性说明
2025-09-28 19:11:53 +08:00

5.0 KiB
Raw Blame History

IEntityService接口泛型修改任务对齐文档

1. 项目上下文分析

1.1 项目结构与技术栈

  • 项目: Contract-Manager
  • 模块: server模块
  • 技术栈: Java 21, Spring Boot 3.3.7, Spring Data JPA 3.3.7, Redis (用于缓存)

1.2 现有代码模式

  • 接口结构: IEntityService接口定义了基础的CRUD操作，泛型T当前用于指定实体类类型
  • VoableService接口: 定义了updateByVo(M model, Vo vo)方法，用于将VO对象的值更新到实体对象
  • Service实现模式: 多个Service类同时实现IEntityService和VoableService接口，分别指定实体类和VO类的泛型参数
  • 缓存配置: 使用@CacheConfig注解配置缓存名称，方法级缓存使用@Cacheable、@CacheEvict等注解
  • 缓存问题: 当前使用实体类进行缓存，由于Hibernate代理对象序列化问题，可能导致懒加载异常

2. 需求理解确认

2.1 原始需求

server模块中注解了 @CacheConfig的Service，调整接口泛型参数，涉及到Service上各个方法的的修改，方法修改相关引用方法的地方也要修改

2.1.1 扩展需求

使用VO替代实体缓存，因为使用redis服务，需要避免代理对象序列化，彻底规避懒加载问题

2.2 边界确认

  • 目标范围: server模块中所有注解了@CacheConfig的Service类
  • 修改内容:
    • Service类继承IEntityService接口，泛型类型保持为Model（实体类）
    • Service类继承QueryService接口，泛型类型修改为Vo（视图对象）
  • 影响范围: 需要同步修改Service类中实现的接口方法的参数和返回类型
  • 任务边界: 不修改接口定义本身，只修改实现类的泛型参数和相关方法实现

2.3 需求理解

  • 当前Service类同时实现IEntityService和VoableService<Entity, Vo>接口，部分还实现了QueryService接口
  • 需要调整Service类的接口实现，使IEntityService保持使用Model类型，QueryService使用Vo类型
  • 修改后，Service类需要根据不同接口的要求实现对应的方法
  • 需要确保缓存注解的键值表达式仍然有效
  • 需要保证修改后系统功能正常运行
  • 使用VO替代实体类进行缓存，避免Hibernate代理对象序列化问题，彻底规避懒加载异常

3. 疑问澄清

  1. 数据转换问题: 如何处理从实体类到VO的转换和从VO到实体类的转换？

    • 系统中已有VoableService接口提供updateByVo方法，可能需要利用现有转换机制

  2. 缓存键表达式: 修改泛型后，缓存注解中的键表达式（如@CacheEvict(key = "#p0.id")）是否需要修改？

    • 需要确认VO类是否与实体类具有相同的属性结构

  3. 依赖影响: 修改Service泛型后，对调用这些Service的其他组件（如Controller、其他Service）会有什么影响？

    • 需要评估依赖影响范围并考虑如何处理

  4. 事务处理: 修改后事务处理是否会受到影响？

    • 需要确保事务边界正确维护

  5. 查询规范: getSpecification方法如何适配从Entity到Vo的转换？

    • Specification是基于JPA实体类的，这可能需要特殊处理

  6. 缓存对象转换: 如何确保缓存中存储的是VO对象而不是实体类对象？

    • 需要确保所有缓存的方法都返回VO对象，并在存储前完成转换

  7. WebSocket服务影响: WebSocketServerCallbackManager类直接调用IEntityService接口，修改泛型后会对WebSocket服务产生什么影响？

    • 需要分析WebSocketServerCallbackManager中的类型处理逻辑，确保其能够适应新的泛型参数
    • 特别关注createNewEntity、findEntityTypeInInterfaces等方法，这些方法依赖于IEntityService的泛型参数

  8. 任务管理影响: WebSocketServerTaskManager类中处理的任务是否会受到接口泛型修改的影响？

    • 需要分析任务执行过程中是否依赖于IEntityService接口的方法调用

4. 初步决策

基于现有项目代码分析，做出以下初步决策：

  1. 泛型修改策略: 对于每个注解了@CacheConfig的Service类，将IEntityService的泛型T从实体类改为对应的VO类

  2. 方法适配方案:

    • 对于返回类型为T的方法，需要在方法内部进行实体类到VO的转换
    • 对于参数为T的方法，需要在方法内部进行VO到实体类的转换
    • 对于findAll等查询方法，需要修改Specification的泛型类型

  3. 缓存键处理: 假设VO类与实体类具有相同的ID属性和其他缓存键中使用的属性，因此缓存注解可能不需要修改

  4. 依赖处理: 需要评估并处理所有调用修改后Service的组件，确保它们适应新的接口定义

  5. 特殊方法处理: 对于getSpecification等基于JPA实体的方法，可能需要特殊处理或保留原有实现

  6. 缓存策略: 确保所有标注@Cacheable的方法都返回VO对象，并在存储前完成从实体类到VO的转换，以避免代理对象序列化问题

这些决策将在后续的共识和设计阶段进一步细化和确认。