Flutter健身应用多Bloc嵌套模型状态数据一致性问题咨询

你的核心问题是嵌套数据结构下，多Bloc各自持有独立状态，导致子层级（比如Set）更新后，父层级（Exercise、Workout）的状态没有同步更新。以下是几种可行的解决方案，各有优劣，你可以根据项目阶段和复杂度选择：

1. 扁平化数据结构 + 单一数据源Bloc（推荐长期方案） #

把嵌套的模型结构改成用ID关联的扁平化设计，每个实体只存储关联对象的ID，而非直接持有对象列表。示例如下：

class Workout extends Equatable {
  final String name;
  final String description;
  final String type;
  final int? id;
  final List<int> exerciseIds; // 存储关联Exercise的ID列表

  const Workout({
    required this.name,
    required this.description,
    required this.type,
    this.id,
    required this.exerciseIds,
  });

  @override
  List<Object?> get props => [name, description, type, id, exerciseIds];
}

class Exercise extends Equatable {
  final String name;
  final String description;
  final int? id;
  final List<int> setIds; // 存储关联Set的ID列表
  final int workoutId; // 关联所属Workout的ID

  const Exercise({
    required this.name,
    required this.description,
    this.id,
    required this.setIds,
    required this.workoutId,
  });

  @override
  List<Object?> get props => [name, description, id, setIds, workoutId];
}

class Set extends Equatable {
  final String name;
  final int reps;
  final int weight;
  final int? id;
  final int exerciseId; // 关联所属Exercise的ID

  const Set({
    required this.name,
    required this.reps,
    required this.weight,
    this.id,
    required this.exerciseId,
  });

  @override
  List<Object?> get props => [name, reps, weight, id, exerciseId];
}

然后创建一个单一的AppDataBloc来管理所有实体的集合：

class AppDataState extends Equatable {
  final Map<int, Workout> workouts;
  final Map<int, Exercise> exercises;
  final Map<int, Set> sets;

  const AppDataState({
    required this.workouts,
    required this.exercises,
    required this.sets,
  });

  @override
  List<Object?> get props => [workouts, exercises, sets];
}

所有数据更新（比如完成一组训练）都通过这个Bloc的事件处理，直接修改对应的Set实体，然后通知状态更新。UI层可以通过ID关联查询需要的数据，比如获取某个Workout的所有Exercise：

List<Exercise> getWorkoutExercises(Workout workout, AppDataState state) {
  return workout.exerciseIds
      .map((id) => state.exercises[id]!)
      .toList();
}

优点：彻底消除数据同步问题，状态有唯一可信源，逻辑集中且结构清晰，后期扩展新功能更方便；
缺点：需要额外处理ID关联的查询逻辑，但可以封装工具方法或扩展类来简化。

2. Bloc间事件监听同步（过渡方案） #

保留现有多Bloc结构，通过监听子Bloc的状态变化来主动更新父Bloc的状态。比如：

• 在ExerciseBloc中监听SetBloc的状态，当Set更新时，找到当前Exercise对应的Set列表并更新；
• 在WorkoutBloc中监听ExerciseBloc的状态，当Exercise更新时，更新对应的Workout的Exercise列表。

示例代码（ExerciseBloc中监听SetBloc）：

class ExerciseBloc extends Bloc<ExerciseEvent, ExerciseState> {
  final SetBloc setBloc;
  late final StreamSubscription _setSubscription;

  ExerciseBloc(this.setBloc) : super(ExerciseInitial()) {
    on<LoadExercise>(_onLoadExercise);
    on<UpdateExercise>(_onUpdateExercise);

    // 监听SetBloc的状态变化
    _setSubscription = setBloc.stream.listen((setState) {
      if (setState is SetUpdated && state is ExerciseLoaded) {
        final updatedSets = state.exercise.sets.map((set) {
          return set.id == setState.updatedSet.id ? setState.updatedSet : set;
        }).toList();
        add(UpdateExercise(state.exercise.copyWith(sets: updatedSets)));
      }
    });
  }

  @override
  Future<void> close() {
    _setSubscription.cancel();
    return super.close();
  }

  // 其他事件处理逻辑...
}

优点：不需要修改现有模型结构，改动成本低；
缺点：容易形成复杂的依赖监听链，代码冗余，后期维护难度高，一旦漏监听就会导致数据不同步。

3. 合并为单一Bloc（谨慎使用） #

把Workout、Exercise、Set的所有逻辑合并到一个WorkoutSessionBloc中，持有完整的嵌套Workout对象，所有操作（更新Set、添加Exercise等）都通过这个Bloc的事件处理。

示例状态类：

class WorkoutSessionState extends Equatable {
  final Workout currentWorkout;

  const WorkoutSessionState({required this.currentWorkout});

  @override
  List<Object?> get props => [currentWorkout];
}

当完成一组训练时，通过事件更新对应的Set，然后生成新的Workout对象并更新状态：

on<CompleteSet>((event, emit) {
  final currentWorkout = state.currentWorkout;
  // 找到对应的Exercise和Set
  final updatedExercises = currentWorkout.exercises.map((exercise) {
    if (exercise.id == event.exerciseId) {
      final updatedSets = exercise.sets.map((set) {
        if (set.id == event.setId) {
          return set.copyWith(name: '已完成'); // 示例更新逻辑
        }
        return set;
      }).toList();
      return exercise.copyWith(sets: updatedSets);
    }
    return exercise;
  }).toList();
  emit(WorkoutSessionState(currentWorkout: currentWorkout.copyWith(exercises: updatedExercises)));
});

优点：状态完全同步，没有多Bloc的同步问题；
缺点：如果业务逻辑复杂，Bloc会变得臃肿，事件和状态类数量激增，代码可读性和可维护性下降。需要确保Equatable正确重写props，避免不必要的UI重建。

方案选择建议 #

• 如果你处于项目初期，优先选择扁平化数据结构+单一数据源Bloc，这是长期维护最友好的方案；
• 如果项目已经有一定规模，不想大规模修改模型，可以先用Bloc间监听同步过渡，后续再逐步重构为扁平化结构；
• 单一Bloc只适合业务逻辑非常简单的场景，不推荐用于中大型项目。

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