flutter_bloc开发中为何在UI层声明repository而非bloc内部声明

这是业界通用的依赖注入规范，核心优势有以下几点：

• 符合依赖倒置设计原则
  业务逻辑层（Bloc）只需要依赖Repository的抽象协议，不需要关心Repository的具体实现、初始化逻辑。如果在Bloc内部直接声明创建Repository实例，会让Bloc和具体Repository实现强耦合，后续要替换Repository实现（比如把线上接口版换成本地Mock版）时必须修改Bloc源码，违反开闭原则。
• 支持多Bloc共享Repository实例
  绝大多数Repository（比如用户认证、账户信息、通用数据请求类）都是全局多模块共用的，在UI根层统一初始化后，既可以通过RepositoryProvider给所有子节点的Bloc提供同一个实例，避免多个Bloc重复创建Repository导致的资源浪费、状态不同步问题。比如全局只有一份AuthenticationRepository实例，所有Bloc读到的登录状态都是统一的，不会出现不同实例状态不一致的异常。
• 大幅降低单元测试成本
  测试Bloc逻辑时，可以直接构造Mock版本的Repository实例传入Bloc，不需要修改Bloc内部的任何代码。如果Repository是在Bloc内部创建的，你要么得修改Bloc源码才能替换成Mock实现，要么需要用非常复杂的反射手段注入，测试效率极低。
  举个测试场景的代码示例：

  // 直接传入Mock实现即可测试Bloc逻辑，不需要修改AuthenticationBloc内部代码
  final mockAuthRepo = MockAuthenticationRepository();
  final bloc = AuthenticationBloc(authenticationRepository: mockAuthRepo);
  

• 统一管理Repository生命周期
  在顶层Widget（比如示例中的MyApp）初始化的Repository，生命周期和应用生命周期对齐，不会因为某个页面/Bloc销毁被回收，内部的缓存、持久化状态可以一直保留。如果在Bloc内部创建Repository，Bloc销毁时Repository也会被回收，下次创建Bloc时需要重新初始化，既浪费性能也容易丢失缓存状态。

你给出的示例代码还可以进一步简化：不需要提前实例化Repository，直接在RepositoryProvider的create方法中初始化即可，核心逻辑都是将Repository的创建、管理和Bloc的业务实现解耦。

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