Flutter(Bloc/Cubit)应用多Repository独立包结构下模型共享问题咨询

针对你描述的分拆独立Repository包的场景，共有3种可行的模型共享方案，可根据你的实际业务需求选择：

方案1：新增独立公共模型包（多应用复用场景最优） #

如果你的多个Repository包未来需要给多个不同的Flutter应用复用，建议新增和其他Repository平级的独立模型包，目录结构参考：

|-app
|-auth_repository
|-friends_repository
|-common_models # 新增的公共模型包
  |-lib
    |-src
      |-user.dart
      |-friend.dart
    |-common_models.dart
  |-pubspec.yaml

操作方式：

• 所有需要复用的通用模型都定义在common_models包中
• auth_repository、friends_repository的pubspec.yaml中引入common_models依赖，内部直接使用公共模型
• 主应用同样引入common_models依赖，Bloc/Cubit层无需做额外模型转换
  优势：模型统一维护，无重复代码，Repository包可独立分发复用。

方案2：Repository内定义专属模型，Bloc层做转换（数据源异构场景适用） #

如果你的不同Repository对接的数据源差异极大，比如AuthRepository对接账号服务、FriendsRepository对接社交中台，两边返回的原始数据结构很难抽象为统一通用模型，可以采用该方案：

• 每个Repository内部定义专属的返回模型，不依赖外部公共模型
• Bloc/Cubit层收到Repository返回的专属模型后，转换为业务层统一的应用内模型再往下传递
  优势：Repository完全和上层业务解耦，数据源接口变更仅需要修改对应Repository和转换逻辑，不会影响上层业务代码。
  劣势：需要编写额外的模型转换代码，存在重复劳动。

方案3：Repository移入主应用目录（单应用场景最优） #

如果你的这些Repository仅服务于当前这一个主应用，没有跨项目复用的需求，完全没必要拆分为独立包，直接调整架构：

• 在主应用的lib目录下新建repositories文件夹，把Auth、Friends相关的Repository代码移入该目录
• 在主应用的lib目录下新建models文件夹，所有通用模型都放在该目录，Repository和Bloc层直接引用即可
  优势：不需要管理多包依赖，开发效率最高，维护成本最低。

选型建议 #

• 有跨应用复用Repository的需求：选方案1
• 各Repository对接的数据源结构差异极大，很难抽象统一模型：选方案2
• 仅当前项目使用Repository：选方案3

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