基于Bloc模式的会话持久化：选择哪一层实现可避免紧耦合？

建议将会话持久化逻辑放在仓库层（LoginRepository），能更好地避免紧耦合，原因如下：

• 仓库层的职责天然适配
  仓库层作为数据层与应用层的中间枢纽，核心职责就是封装数据的获取、缓存、转换逻辑，对外提供统一的数据访问接口。把会话持久化整合到LoginRepository后，应用层所有Cubit只需要订阅仓库暴露的Stream<Session>，完全无需关心会话是来自远程请求还是本地缓存，彻底解耦了持久化的具体实现细节。

• 避免数据层职责混杂
  数据层的AppApi应该聚焦在远程数据交互（即单纯从服务器请求会话码），如果把持久化逻辑放在这里，会违反单一职责原则，让AppApi同时承担远程请求和本地存储两个无关职责。后续如果更换持久化方案（比如从SharedPreferences切换到Hive），就需要修改数据层代码，而仓库层可以隔离这类变化，应用层完全不受影响。

• 实现思路参考

  1. 在LoginRepository内部整合持久化逻辑：初始化时先从本地读取缓存的会话，作为会话流的初始值；当从AppApi获取到新会话后，同步写入本地存储。
  2. 仓库对外暴露的Stream<Session>整合本地缓存和远程更新的数据流，确保应用层能实时拿到最新的有效会话。
  3. 应用层的Cubit通过依赖注入获取LoginRepository实例，直接通过StreamSubscription订阅会话流，无需再通过SessionCubit中转，进一步简化层级并降低耦合。

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