Flutter BLoC架构下嵌套数据结构的合理性咨询

当前设计概述 #

• 数据结构：
  • User → 包含List<WorkoutPlan>
  • WorkoutPlan → 包含List<Workout>
  • Workout → 包含List<Exercise>
• 存储方案：
  • user.json：仅存储训练计划ID列表
  • workoutPlans.json：每个训练计划存储对应的训练项ID列表
  • workouts.json：存储训练项的完整数据
• 状态管理：对应UserBloc、WorkoutPlanBloc、WorkoutBloc三个独立Bloc
• 页面：用户信息页、训练计划列表页、选中计划的训练项列表页

核心问题：设计局限性导致跨页面依赖复杂 #

当前的数据结构和存储方案本身没有本质错误，但确实存在加剧跨页面数据依赖复杂度的设计缺陷：

1. 仅靠ID维系嵌套关联，跨层级数据获取成本高 #

实体间是强嵌套关联，但存储时只保留ID引用，未冗余必要元数据。比如用户页要展示最近使用的训练项，需要：

• 从user.json拿到训练计划ID
• 遍历workoutPlans.json匹配对应计划的训练项ID
• 再从workouts.json中逐个提取训练项数据
  这个流程需要跨多个Bloc发起异步请求，不仅增加了逻辑复杂度，还容易出现数据加载时序混乱（比如训练项数据未加载完成时，用户页已开始渲染）。

2. Bloc职责边界模糊，耦合度上升 #

每个Bloc本应只负责自身实体的状态管理，但因跨页面需求（如用户页需训练项数据），UserBloc不得不依赖WorkoutBloc的数据，打破了单一职责原则。这会导致Bloc间耦合度提升，状态同步难度增加——比如训练项数据更新时，用户页需要手动监听WorkoutBloc的状态变化来触发刷新。

3. 未针对高频跨场景需求做优化 #

对于"最近使用的训练项"这类跨层级高频需求，当前设计没有任何冗余优化，每次都需要从底层逐层查询，既影响性能，也加重了页面逻辑的负担。

优化建议 #

1. 补充轻量元数据冗余 #

• 在user.json中，除训练计划ID外，新增最近使用的训练项ID列表（甚至包含训练项名称、时长等轻量元数据），避免每次都从底层遍历查询。
• 在workoutPlans.json中，为每个训练项ID附加基础元数据（如名称、缩略图路径），让训练计划列表页无需依赖WorkoutBloc就能展示基础信息。

2. 调整Bloc职责，引入统一数据层 #

• 新增DataRepository作为全局数据访问层，封装所有JSON文件的读写逻辑，各个Bloc不再直接操作文件，而是通过Repository获取数据。跨层级数据查询的逻辑放在Repository中处理，Bloc仅负责状态管理。
• 对于跨页面共享的数据（如最近使用记录），可使用全局AppBloc或SharedDataBloc维护，避免多个Bloc间的耦合。

3. 重构存储结构（可选，视需求复杂度） #

如果后续跨场景需求增多，可调整存储结构：

• 将用户的最近使用记录单独存储在user_recents.json中，直接关联训练项ID和基础元数据，用户页可直接读取该文件，无需依赖其他数据文件。
• 保留ID引用的同时，在顶层实体中缓存常用子实体的元数据，平衡数据一致性与访问效率。

内容的提问来源于stack exchange，提问作者Mate282