架构设计模式：依赖注入最佳实践

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

架构设计模式：依赖注入最佳实践

在开发可维护、可测试且具备良好扩展性的Flutter应用过程中，依赖注入（Dependency Injection, DI）是一种至关重要的设计模式。它不仅能有效降低模块间的耦合程度，还显著提升了单元测试的便利性。本文将从核心概念入手，系统分析Flutter中实现依赖注入的多种方式，并深入探讨结合特定工具的工程化落地策略，同时分享适用于大型项目的实际经验。

get_it

injectable

一、理解依赖注入的核心原理

1.1 依赖注入的本质

依赖注入是控制反转（Inversion of Control, IoC）思想的具体体现之一。其核心理念在于：一个类不应自行创建其所依赖的对象实例，而应由外部环境通过构造函数、Setter方法或专用的DI容器来提供这些依赖项。

未使用DI的情况（高耦合示例）：

class UserRepository {
  // 内部直接初始化 ApiService
  // 导致与 ApiService 强绑定，难以替换（如测试时无法使用Mock）
  final ApiService _apiService = ApiService();

  Future<User> getUser() async {
    return _apiService.fetchUser();
  }
}

采用DI后的写法（低耦合示例）：

class UserRepository {
  final ApiService _apiService;

  // 依赖通过构造函数传入
  UserRepository(this._apiService);

  Future<User> getUser() async {
    return _apiService.fetchUser();
  }
}

1.2 使用依赖注入的关键优势

• 解耦能力增强：类不再负责创建依赖对象，仅需关注如何使用它们，职责更加清晰。
• 提升可测试性：在编写单元测试时，可以轻松注入模拟对象（Mock），替代真实的网络服务或数据库访问层。
• 改善可维护性：整体依赖关系明确，代码结构更易于阅读和重构。
• 支持生命周期管理：现代DI框架通常提供对单例、懒加载、工厂模式等对象生命周期的统一控制机制。

二、Flutter生态中的依赖注入方案对比

在Flutter项目中，开发者可以根据项目规模和复杂度选择合适的DI实现方式，从手动管理到自动化生成均有成熟方案可供选择。

2.1 构造函数注入（Constructor Injection）

这是最基础也是推荐优先使用的注入方式，即通过类的构造函数传递所需依赖。

优点：实现简单直观，无需引入第三方库，类型安全且易于调试。

缺点：当依赖层级较深时（例如A依赖B，B依赖C……），顶层组件需要逐层传递依赖，导致“Prop Drilling”问题，增加组装成本。

2.2 基于 InheritedWidget 的 Provider 方案

Provider

Provider 是对 Flutter 原生 InheritedWidget 的封装，实现了轻量级的状态管理和依赖注入功能。

InheritedWidget

优点：被官方推荐使用，能与Widget树的生命周期无缝集成，天然支持响应式更新机制。

缺点：必须依赖 BuildContext 才能获取依赖，在非UI逻辑层（如纯Dart的服务层或数据仓库）中使用不够灵活。

BuildContext

2.3 使用 GetIt 实现服务定位模式

GetIt

GetIt 是一个轻量高效的服务定位器（Service Locator），允许在整个应用程序范围内注册并获取对象实例，不依赖于UI上下文。

优点：查找性能极高（时间复杂度为O(1)），可在任意位置调用，特别适合用于BLoC、ViewModel 或 Repository 层。

缺点：若过度使用（如在UI组件中频繁直接调用 GetIt.get()），会导致依赖关系隐式化，削弱代码的可读性和可追踪性，容易演变为“全局变量”的反模式。

GetIt.I

2.4 结合 Injectable 进行代码生成

Injectable

Injectable 是基于注解的代码生成库，构建在 GetIt 之上，通过声明式注解自动生成依赖注册代码。

优点：避免了手动编写大量重复的注册逻辑，支持开发/生产环境区分配置，便于模块化组织依赖注册逻辑。

推荐组合：GetIt + Injectable 已成为当前Flutter大型项目中最主流的依赖注入解决方案，兼顾灵活性与开发效率。

GetIt

三、实战演练：GetIt 与 Injectable 的协同应用

接下来我们将展示如何在一个真实项目中整合 GetIt 和 Injectable 来高效管理依赖关系。

3.1 添加项目依赖

在 pubspec.yaml 文件中添加以下配置：

pubspec.yaml

dependencies:
  flutter:
    sdk: flutter
  get_it: ^7.6.0
  injectable: ^2.3.0

dev_dependencies:
  build_runner: ^2.4.6
  injectable_generator: ^2.4.1

3.2 初始化依赖注入容器

创建一个独立的注入配置文件，用于集中管理所有依赖的注册过程。

injection.dart

// lib/core/di/injection.dart

final getIt = GetIt.instance;

@InjectableInit(
  initializerName: 'init',
  preferRelativeImports: true,
  asExtension: true,
)
void configureDependencies() => getIt.init();

3.3 声明依赖与使用注解

以用户认证功能为例，说明如何定义和注入服务。

1. 定义抽象接口（推荐方式）

通过抽象类声明服务契约，便于解耦和测试。

// lib/features/auth/domain/i_auth_service.dart
abstract class IAuthService {
  Future<bool> login(String username, String password);
}

2. 实现具体逻辑并添加注入注解

使用以下注解标记实现类：

@Injectable

或

@Singleton

/

@LazySingleton

// lib/features/auth/data/auth_service_impl.dart
import 'package:injectable/injectable.dart';
import '../domain/i_auth_service.dart';

@LazySingleton(as: IAuthService)
class AuthServiceImpl implements IAuthService {
  @override
  Future<bool> login(String username, String password) async {
    await Future.delayed(Duration(seconds: 1));
    return username == 'admin' && password == '123456';
  }
}

3. 在业务组件中注入依赖

在 ViewModel 或 BLoC 等组件中，通过构造函数自动注入所需服务。框架将根据注解生成对应的依赖解析代码。

// lib/features/auth/presentation/auth_viewmodel.dart
import 'package:flutter/foundation.dart';
import 'package:injectable/injectable.dart';
import '../domain/i_auth_service.dart';

@injectable
class AuthViewModel extends ChangeNotifier {
  final IAuthService _authService;

  AuthViewModel(this._authService);

  bool _isLoading = false;
  bool get isLoading => _isLoading;

  Future<void> login(String username, String password) async {
    _isLoading = true;
    notifyListeners();

    final success = await _authService.login(username, password);
    print(success ? 'Login Success' : 'Login Failed');

    _isLoading = false;
    notifyListeners();
  }
}

IAuthService

injectable

3.4 注册第三方库的依赖模块

对于无法直接修改源码的外部库（例如网络请求库或本地存储库），可通过独立模块进行注册。

支持注入如下的第三方实例：

Dio

,

SharedPreferences

此时应使用如下方式声明注册模块：

@module

// lib/core/di/register_module.dart
import 'package:dio/dio.dart';
import 'package:injectable/injectable.dart';
import 'package:shared_preferences/shared_preferences.dart';

@module
abstract class RegisterModule {

// 注册 Dio 实例，配置基础选项
@lazySingleton
Dio get dio => Dio(BaseOptions(baseUrl: 'https://api.example.com'));

// 异步初始化依赖项，例如 SharedPreferences
@preResolve
Future<SharedPreferences> get prefs => SharedPreferences.getInstance();

3.6 在 main.dart 中完成初始化操作

在应用入口处进行依赖注入系统的初始化。

// lib/main.dart
import 'package:flutter/material.dart';
import 'core/di/injection.dart';
import 'features/auth/presentation/auth_viewmodel.dart';
import 'package:provider/provider.dart';

void main() async {
  WidgetsFlutterBinding.ensureInitialized();
  // 执行依赖配置初始化
  await configureDependencies();
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: ChangeNotifierProvider(
        // 通过 GetIt 获取 AuthViewModel 实例
        create: (_) => getIt<AuthViewModel>(),
        child: LoginScreen(),
      ),
    );
  }
}

3.5 运行 build_runner 生成必要代码

使用代码生成工具自动生成依赖注入所需的绑定代码。

injection.config.dart

flutter pub run build_runner build --delete-conflicting-outputs

四、依赖注入的最佳实践

4.2 环境区分（Environment Configuration）

支持根据不同环境注册不同的实现。例如开发环境使用模拟服务，生产环境使用真实接口。

@Environment(Environment.dev)
@Injectable(as: IAuthService)
class MockAuthService implements IAuthService { ... }

@Environment(Environment.prod)
@Injectable(as: IAuthService)
class RealAuthService implements IAuthService { ... }

在初始化时指定当前运行环境：

getIt.init(environment: Environment.prod);

Injectable

4.1 面向抽象编程（Programming to Interfaces）

应始终依赖于接口或抽象类，而非具体实现类。

推荐做法（Good）：

AuthViewModel(this._authService)

其中

_authService

是

IAuthService

类型的实现。

不推荐做法（Bad）：

AuthViewModel(this._authService)

其中

_authService

是

AuthServiceImpl

类型的具体类。

这种设计的优势在于：测试时可轻松注入模拟对象

MockAuthService

，并且在更换底层实现（如从 HTTP 切换到 Firebase）时无需修改 ViewModel 的逻辑。

4.4 合理管理对象作用域（Scoping）

根据对象的用途选择合适的生命周期策略。

• Singleton / LazySingleton：适用于全局共享的服务实例，例如

ApiService

、

AuthService

、

Database

• Factory (@injectable)：每次请求都创建新实例，适合用于

Bloc

、

ViewModel

，或包含独立状态、不应被多个组件共享的对象。

4.3 避免 Service Locator 反模式

尽管

getIt

允许在任意位置调用

getIt<T>()

获取实例，但应避免在类内部直接使用它。

反面示例（Bad）：

class UserProfile {
  void load() {
    // 隐式依赖，难以追踪和测试
    final api = GetIt.I<ApiService>();
    api.fetch();
  }
}

正确方式（Good）：

class UserProfile {
  final ApiService _api;

  // 通过构造函数显式声明依赖
  UserProfile(this._api);

  void load() => _api.fetch();
}

仅在“组合根（Composition Root）”中使用

getIt

来组装对象，例如在

main.dart

、

Route

的定义处，或

Provider

中的

create

方法内。

五、常见面试题解析

5.1 依赖注入与依赖查找（Service Locator）有何区别？

答：

依赖注入（DI）是一种将依赖对象通过外部容器主动传入目标类的设计模式，通常通过构造函数、属性或方法参数传递。这种方式使得依赖关系清晰、易于测试和维护。

而依赖查找（即 Service Locator 模式）则是类在内部主动从一个全局容器中获取所需服务，隐藏了真实的依赖来源，导致耦合度升高，不利于单元测试和重构。

因此，推荐使用依赖注入而非依赖查找，以保持代码的高内聚、低耦合特性。

依赖注入（DI）与依赖查找（Service Locator）的核心区别在于获取依赖的方式不同。

依赖注入（Dependency Injection）：采用被动方式实现。类通过构造函数声明其所需的依赖项，由外部容器负责将这些依赖“注入”进来。整个过程中，类本身并不知晓容器的存在，完全解耦于容器逻辑。

依赖查找（Service Locator）：属于主动模式。类需要显式地向服务定位器（即容器）请求所需的依赖对象（例如通过调用特定方法获取）。这意味着类必须依赖于容器的接口，从而引入了对容器的直接耦合。

通常情况下，依赖注入优于服务定位器模式，因为 DI 让依赖关系更加明确，并且在单元测试时更易于管理——无需模拟整个容器即可完成测试。

5.2 GetIt 中 Factory 与 Singleton 的差异是什么？

Factory：每次调用获取实例时，都会重新执行注册时提供的工厂函数，返回一个全新的对象实例。这种模式适用于具有独立状态、不需要共享的场景，比如页面级别的 Bloc 或 ViewModel。

Singleton：首次请求时创建实例，后续所有调用均返回同一实例，确保全局唯一性。

LazySingleton：行为类似于 Singleton，但实例的创建被延迟到第一次被请求时才进行，有助于优化应用启动性能。

getIt<T>()

5.3 如何处理存在循环依赖的情况？

当出现类 A 依赖类 B，而类 B 又反过来依赖类 A 时，就构成了循环依赖。这通常是代码设计不合理的表现。

解决方案一（重构）：将 A 和 B 共有的功能或数据提取到一个新的类 C 中，然后让 A 和 B 都依赖 C，从而打破原有的循环引用结构。

解决方案二（延迟获取）：不在构造函数中直接传入依赖，而是在实际使用时再动态获取。例如，在某些情况下可通过

GetIt

结合

getIt.registerLazySingleton

并在内部调用

getIt()

来实现按需获取，但这种方式会增加运行时风险和复杂度。

最佳实践：从根本上重新审视并优化系统架构，彻底消除循环依赖，提升模块间的清晰边界。

5.4 InheritedWidget 和 Provider 是否属于依赖注入？

是的，它们实现了某种形式的依赖注入，常被称为“基于组件树的依赖注入”。这类机制允许数据沿着 Widget 树从上至下传递，子组件可以直接获取祖先节点所提供的依赖，而无需通过层层构造函数手动传递。

其中，

Provider

已成为当前 Flutter 开发生态中最流行的轻量级依赖注入方案之一，尤其适合用于 UI 层的状态管理和依赖共享。

六、总结

依赖注入是构建高质量、可维护 Flutter 应用的重要基础。

核心价值：实现模块间解耦、提升代码可测试性与可维护性。

工具选择建议：

• 小型项目：可直接使用简单的构造函数注入，或借助

  Provider

  实现基本管理。
• 中大型项目：推荐使用 GetIt + Injectable 组合方案。该组合支持类型安全、编译期检查以及自动化代码生成，能高效应对复杂的依赖管理体系。

设计原则提醒：

• 坚持面向接口编程；
• 合理规划对象的生命周期；
• 避免过度使用 Service Locator 模式，以防造成隐式依赖和测试困难。

通过科学地运用依赖注入技术，你的 Flutter 项目将拥有更清晰的结构和更高的代码质量。

GetIt.I<Service>()

GetIt

getIt.registerLazySingleton

getIt()

Provider

Provider

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：最佳实践 Presentation environment Preferences Presentatio