Files
contract-manager/docs/task/server模块service缓存调整为Vo对象/ALIGNMENT_server_service_cache_vo.md
songqq 49413ad473 refactor(service): 统一Service缓存为VO对象并优化关联实体处理
重构Service类实现,将QueryService泛型参数调整为VO类型,确保缓存VO对象而非实体。优化关联实体处理逻辑,减少重复代码。修改findById方法返回VO对象,新增getById方法获取实体。更新相关调用点以适配新接口。

调整WebSocket处理、控制器及Service实现,确保数据类型一致性。完善文档记录重构过程及发现的问题。为后续优化提供基础架构支持。
2025-09-29 19:31:51 +08:00

5.8 KiB
Raw Permalink Blame History

Server模块Service缓存调整为Vo对象 - ALIGNMENT文档

1. 项目上下文分析

1.1 项目结构

Contract-Manager是一个基于Java技术栈的合同管理系统包含三个主要模块

  • server模块基于Spring Boot 3.3.7的后端服务负责数据持久化、业务逻辑处理和WebSocket通信
  • client模块基于JavaFX 21的桌面客户端负责用户界面和与server模块的通信
  • common模块公共组件库被server和client模块共同依赖

1.2 技术栈

server模块

  • Java 21
  • Spring Boot 3.3.7
  • Spring Data JPA 3.3.7
  • MySQL 8.0.33
  • Lombok 1.18.32
  • POI 5.2.5
  • PDFBox 3.0.1
  • Redis用于缓存

1.3 架构模式

系统采用经典的三层架构:

  • 数据访问层Repository接口负责数据持久化
  • 业务逻辑层Service类负责业务逻辑处理和缓存管理
  • 表示层Controller和WebSocket服务负责请求处理和响应

1.4 核心组件

1.4.1 Service层

Service层是系统的核心业务层包含了大量的Service类主要特点

  • 大多数Service类实现了IEntityService、QueryService和VoableService三个接口
  • 使用@CacheConfig、@Cacheable、@CacheEvict等注解进行缓存管理
  • 负责实体类和VO类之间的转换
  • 被WebSocket服务通过反射机制动态调用

1.4.2 WebSocket服务

WebSocket服务是系统的通信核心主要组件

  • WebSocketServerHandler负责WebSocket会话管理
  • WebSocketServerTaskManager负责任务调度
  • WebSocketServerCallbackManager负责处理客户端消息并调用相应的Service方法

1.4.3 实体类和VO类

  • 实体类Model与数据库表一一对应使用JPA注解映射
  • VO类View Object用于前端展示和WebSocket通信包含简化的数据结构
  • 实体类通常实现Voable接口提供toVo方法将自身转换为VO对象

2. 需求理解确认

2.1 原始需求

原始需求根据任务文档Server模块Service缓存调整为Vo对象执行任务1。

2.2 任务文档需求

根据任务文档任务1的具体需求是

  • 分析现有Service类结构和依赖关系
  • 输出Service类结构分析报告
  • 绘制依赖关系图
  • 分析与其他组件的依赖关系
  • 特别关注WebSocketServerCallbackManager与IEntityService接口的交互逻辑
  • 记录IEntityService、QueryService、VoableService泛型参数
  • 记录特殊方法和缓存配置

2.3 边界确认

  • 任务范围仅限于Server模块中注解了@CacheConfig的Service类
  • 输入:项目源代码、任务文档
  • 输出Service类结构分析报告、ALIGNMENT文档、CONSENSUS文档、DESIGN文档、TASK文档
  • 排除项不涉及client模块和common模块的修改
  • 时间约束按照6A工作流的阶段划分逐步执行

3. 智能决策策略

3.1 歧义识别

  1. 缓存调整为Vo对象的具体含义需要进一步明确是将缓存的键还是值调整为Vo对象

    • 决策根据任务文档的上下文应该是指将缓存的值从实体对象调整为Vo对象
  2. IEntityService接口中getById方法不能使用@Cacheable注解的原因:需要明确是所有情况还是特定情况

    • 决策:根据分析,是当实体类有关联实体时不能使用@Cacheable注解
  3. WebSocketServerCallbackManager如何动态识别和调用不同Service的方法:需要明确具体的实现机制

    • 决策通过反射机制分析Service类的接口、父类和方法参数来确定实体类型

3.2 结构化问题清单

  1. 哪些Service类同时实现了IEntityService、QueryService和VoableService三个接口
  2. WebSocketServerCallbackManager如何处理不同类型的Service方法调用
  3. 当前系统的缓存策略有哪些特点和不足?
  4. 实体类和VO类之间的转换机制是否统一
  5. 如何确保缓存调整后不影响系统的正常运行?

4. 疑问澄清

  1. 缓存调整的具体目标是完全替换实体对象缓存为Vo对象缓存还是新增Vo对象缓存

    • 假设根据任务名称应该是将现有的实体对象缓存调整为Vo对象缓存
  2. 缓存键的设计:是否需要统一缓存键的命名规则?

    • 假设:是的,统一的缓存键命名规则有助于提高系统的可维护性
  3. 多接口实现的泛型参数如何确保Service类实现多个接口时泛型参数的一致性

    • 假设:需要制定统一的规范,确保泛型参数的使用一致
  4. WebSocket通信的兼容性缓存调整后是否需要修改WebSocket通信的逻辑

    • 假设可能需要修改WebSocketServerCallbackManager中处理缓存的逻辑以确保兼容性
  5. 测试策略:如何验证缓存调整的正确性和性能?

    • 假设:需要编写单元测试和集成测试,测试缓存的读写、清理等操作

5. 项目特性规范

5.1 文件命名规范

  • 分析报告文件:ANALYSIS_service_class_structure.md
  • ALIGNMENT文档ALIGNMENT_server_service_cache_vo.md
  • CONSENSUS文档CONSENSUS_server_service_cache_vo.md
  • DESIGN文档DESIGN_server_service_cache_vo.md
  • TASK文档TASK_server_service_cache_vo.md

5.2 文档格式规范

  • 所有文档使用Markdown格式
  • 文档结构清晰,包含标题、小标题和列表
  • 使用代码块展示代码示例
  • 使用mermaid绘制架构图和依赖关系图

5.3 代码规范

  • 遵循项目现有的代码规范
  • 使用Lombok注解简化代码
  • 类和方法应有适当的JavaDoc注释
  • 缓存注解的使用应符合项目规范

6. 下一步计划

  1. 完成ALIGNMENT文档
  2. 创建CONSENSUS文档确认所有不确定性
  3. 创建DESIGN文档设计系统架构和接口规范
  4. 创建TASK文档拆分原子任务
  5. 按计划执行原子任务