如何用Riverpod简化依赖访问？不使用单例或服务定位器

问题1：不依赖单例或服务定位器的简化方案 #

1. 构造函数注入（推荐，符合DI原则） #

核心思路是将依赖通过构造函数传递给需要的类，而非让类主动获取依赖。这样类本身与Riverpod解耦，更易测试和维护。

示例：

// 先定义Logger相关的Provider
final loggerConfigProvider = Provider<LoggerConfig>((ref) {
  return LoggerConfig(
    logSeverity: environment.tryGetString('LOG_LEVEL'),
  );
});

final loggerProvider = Provider<LoggerContract>((ref) {
  final config = ref.watch(loggerConfigProvider);
  return Logger(config);
});

// 需要使用Logger的业务类
class UserService {
  final LoggerContract _logger;

  // 通过构造函数注入Logger
  UserService(this._logger);

  void fetchUser() {
    _logger.log('开始获取用户数据');
    // 业务逻辑...
  }
}

// 为业务类创建Provider，自动注入依赖
final userServiceProvider = Provider<UserService>((ref) {
  final logger = ref.watch(loggerProvider);
  return UserService(logger);
});

使用时只需读取业务类的Provider，无需单独处理Logger：

final userService = ref.read(userServiceProvider);
userService.fetchUser();

这种方式的优势：

• 类的职责单一，无需关心依赖来源
• 测试时可轻松传入MockLogger，无需修改全局状态
• 完全符合Riverpod的依赖注入设计理念

2. 为Ref添加扩展方法（简化频繁调用） #

如果需要在大量Widget或Provider中直接访问Logger，可以给WidgetRef或ProviderRef编写扩展方法，减少重复代码：

// 扩展WidgetRef，方便在Widget中使用
extension LoggerRefExtension on WidgetRef {
  LoggerContract get logger => read(loggerProvider);
}

// 扩展ProviderRef，方便在Provider中使用
extension LoggerProviderRefExtension on ProviderRefBase {
  LoggerContract get logger => read(loggerProvider);
}

使用时直接通过ref调用：

// 在Widget中
ref.logger.log('Widget渲染完成');

// 在Provider中
final someProvider = Provider((ref) {
  ref.logger.log('Provider初始化');
  // ...
});

这种方式既保留了Riverpod的响应式和可测试性，又减少了样板代码，不会引入全局单例的问题。

问题2：Riverpod中全局访问依赖的惯用方式 #

Riverpod不推荐全局直接访问Provider（这会退回到服务定位器模式，破坏依赖追踪和可测试性），但可以通过以下方式减少样板：

• 复合Provider封装常用依赖：如果有一组经常搭配使用的依赖（比如Logger + ApiClient），可以创建复合Provider封装，但这种场景不如构造函数注入清晰。
• ScopedProvider（局部作用域场景）：如果需要在某个局部作用域内共享依赖，可使用ScopedProvider，但仅适合特定场景，全局场景仍推荐构造函数注入或扩展方法。

关键注意事项 #

• 避免手动单例：手动创建的全局ProviderContainer实例会导致测试时无法灵活替换依赖，丧失Riverpod的核心优势。
• 保持依赖追踪：所有依赖访问都通过ref进行，Riverpod会自动追踪依赖关系，确保状态更新时相关组件/Provider能响应。

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