refactor(model): 重构模型类包结构并优化序列化处理

重构模型类包结构，将模型类按功能模块划分到不同的子包中。优化序列化处理，为VO类添加serialVersionUID并实现Serializable接口。移除部分冗余的serialVersionUID字段，简化模型类代码。同时修复UITools中空值处理的问题，并更新pom版本至0.0.100-SNAPSHOT。 - 将模型类按功能模块划分到ds子包中 - 为VO类添加序列化支持 - 移除冗余的serialVersionUID字段 - 修复UITools空值处理问题 - 更新项目版本号
2025-10-09 18:27:48 +08:00
parent 51b8c16798
commit c4eec0a9dd
457 changed files with 8426 additions and 3669 deletions
--- a/docs/task/server模块service缓存调整为Vo对象/MODIFICATION_plan_affected_components.md
+++ b/docs/task/server模块service缓存调整为Vo对象/MODIFICATION_plan_affected_components.md
@@ -0,0 +1,175 @@
+# 受影响组件修改方案
+
+## 1. 概述
+
+本方案针对Server模块Service缓存从实体对象调整为VO对象后受影响的依赖组件，提供具体的修改和优化建议，确保系统的兼容性、稳定性和性能。
+
+## 2. WebSocketServerCallbackManager修改方案
+
+### 2.1 核心优化点
+
+1. **实体类型识别优化**
+   - 优化`createNewEntity`方法中的实体类型识别逻辑
+   - 增加缓存机制，避免重复解析类型信息
+   - 提供更明确的错误信息和日志
+
+2. **类型安全增强**
+   - 添加更多的类型检查和异常处理
+   - 优化反射调用的安全性
+
+### 2.2 代码优化建议
+
+```java
+private <T> T createNewEntity(IEntityService<T> entityService) {
+    try {
+        // 获取服务类
+        Class<?> serviceClass = entityService.getClass();
+        
+        // 优化点1: 使用缓存存储已解析的实体类型
+        Class<T> entityClass = getEntityTypeFromCache(serviceClass);
+        if (entityClass != null) {
+            return entityClass.getDeclaredConstructor().newInstance();
+        }
+
+        // 1. 直接检查接口
+        entityClass = findEntityTypeInInterfaces(serviceClass);
+        if (entityClass != null) {
+            cacheEntityType(serviceClass, entityClass);
+            return entityClass.getDeclaredConstructor().newInstance();
+        }
+
+        // 2. 处理Spring代理类 - 获取原始类
+        Class<?> targetClass = getTargetClass(serviceClass);
+        if (targetClass != serviceClass) {
+            entityClass = findEntityTypeInInterfaces(targetClass);
+            if (entityClass != null) {
+                cacheEntityType(serviceClass, entityClass);
+                return entityClass.getDeclaredConstructor().newInstance();
+            }
+        }
+
+        // 3. 尝试查找父类
+        entityClass = findEntityTypeInSuperclass(serviceClass);
+        if (entityClass != null) {
+            cacheEntityType(serviceClass, entityClass);
+            return entityClass.getDeclaredConstructor().newInstance();
+        }
+
+        // 4. 如果上述方法都失败，尝试从参数类型推断
+        entityClass = findEntityTypeFromMethodParameters(serviceClass);
+        if (entityClass != null) {
+            cacheEntityType(serviceClass, entityClass);
+            return entityClass.getDeclaredConstructor().newInstance();
+        }
+
+        // 如果所有方法都失败，抛出更具描述性的异常
+        throw new UnsupportedOperationException("无法确定实体类型，请检查服务实现: " + serviceClass.getName());
+    } catch (Exception e) {
+        logger.error("无法创建Entity实例: {}", e.getMessage(), e);
+        throw new RuntimeException("无法创建Entity实例: " + e.getMessage(), e);
+    }
+}
+
+// 添加缓存机制
+private final Map<Class<?>, Class<?>> entityTypeCache = new ConcurrentHashMap<>();
+
+private <T> Class<T> getEntityTypeFromCache(Class<?> serviceClass) {
+    @SuppressWarnings("unchecked")
+    Class<T> entityClass = (Class<T>) entityTypeCache.get(serviceClass);
+    return entityClass;
+}
+
+private void cacheEntityType(Class<?> serviceClass, Class<?> entityClass) {
+    entityTypeCache.put(serviceClass, entityClass);
+}
+```
+
+## 3. Service实现类优化方案
+
+### 3.1 updateByVo方法标准化
+
+确保所有Service类的updateByVo方法遵循统一的实现规范：
+
+1. **字段映射规范**
+   - 确保所有基本字段正确映射
+   - 关联实体使用SpringApp.getBean()获取相应Service并调用findById()方法
+   - 特殊字段（如日期、枚举等）进行适当的类型转换
+
+2. **版本控制处理**
+   - 对于有@Version注解的字段，在updateByVo方法中检查版本号一致性
+   - 不一致时记录警告日志
+
+### 3.2 缓存配置优化
+
+1. **缓存键表达式验证**
+   - 确保所有@Cacheable、@CacheEvict等注解的键值表达式正确引用VO对象的属性
+   - 检查缓存命名的一致性
+
+2. **缓存清理策略**
+   - 实施Redis缓存清理计划
+   - 确保新旧缓存数据不会冲突
+
+## 4. 测试验证方案
+
+### 4.1 单元测试
+
+1. **Service方法测试**
+   - 测试findById、findAll等方法返回VO对象
+   - 测试updateByVo方法正确更新实体属性
+   - 测试缓存注解正确应用
+
+2. **WebSocket通信测试**
+   - 测试通过WebSocket调用Service方法获取VO对象
+   - 测试通过WebSocket提交数据更新实体
+
+### 4.2 集成测试
+
+1. **端到端测试**
+   - 客户端发起请求到服务器，验证数据转换的正确性
+   - 测试各种场景下的数据一致性
+
+2. **性能测试**
+   - 测试VO对象缓存与实体对象缓存的性能差异
+   - 评估系统整体性能影响
+
+## 5. 实施计划
+
+### 5.1 阶段一：代码优化
+- 完成WebSocketServerCallbackManager的优化
+- 标准化所有Service类的updateByVo方法
+- 验证缓存配置
+
+### 5.2 阶段二：测试验证
+- 执行单元测试和集成测试
+- 修复发现的问题
+
+### 5.3 阶段三：部署和缓存清理
+- 部署优化后的代码
+- 执行Redis缓存清理
+- 监控系统运行状态
+
+## 6. 风险评估与应对
+
+### 6.1 潜在风险
+
+1. **类型识别失败**
+   - 风险：某些Service可能无法正确识别实体类型
+   - 应对：加强类型识别逻辑，提供备用方案
+
+2. **缓存不一致**
+   - 风险：新旧缓存数据可能导致系统行为异常
+   - 应对：部署后执行全面的缓存清理
+
+3. **性能影响**
+   - 风险：实体-VO转换可能带来性能开销
+   - 应对：优化转换逻辑，添加适当的缓存机制
+
+### 6.2 监控与告警
+
+- 添加关键组件的日志监控
+- 设置异常告警机制
+- 定期检查系统性能指标
+
+## 7. 结论
+
+通过实施本修改方案，可以有效处理Service缓存调整为VO对象后对依赖组件的影响，确保系统的兼容性、稳定性和性能。实施过程中应严格遵循测试验证流程，并做好风险应对准备。