依赖注入 (Dependency Injection, DI)
依赖注入是一种设计模式，用于实现 控制反转（Inversion of Control, IoC），目的是解耦系统中的各个组件，使得它们更加灵活、可测试，并且易于维护。简单来说，依赖注入的核心概念是将一个对象所依赖的组件或服务由外部注入，而不是由对象自己创建或管理。
在 ASP.NET Core 中，依赖注入是框架的一部分，几乎所有的服务（如数据库上下文、日志、缓存等）都可以通过依赖注入来提供。
1. 依赖注入的基本概念
什么是依赖注入
依赖注入是将组件的依赖关系从外部注入到该组件中，而不是让该组件自己去创建和管理这些依赖关系。这样可以解耦系统中的各个部分，降低代码之间的耦合度，使得系统更加灵活，易于测试和扩展。
例如，一个服务可能需要数据库上下文 (DbContext) 或日志服务 (ILogger) 来完成其功能。依赖注入将这些服务自动传递给该服务，而不需要该服务自己创建这些依赖项。
依赖注入的三种主要方式
- 构造函数注入（Constructor Injection）：通过构造函数将依赖项注入到类中。
- 属性注入（Property Injection）：通过设置对象的属性来注入依赖项。
- 方法注入（Method Injection）：通过方法的参数来注入依赖项。
在 依赖注入 （Dependency Injection，简称 DI）中，通常有三种常见的服务生命周期模式，用于控制服务实例的创建和管理。这些模式分别是：Transient 、Scoped 和 Singleton 。这三种模式在 ASP.NET Core 中非常重要，因为它们决定了依赖项在应用程序中的生命周期。以下是这三种模式的详细解释：
1. Transient（瞬态）
- 生命周期： 每次请求都会创建一个新的服务实例。
- 适用场景： 短生命周期、无状态的服务。每次注入时需要一个新的对象实例。
- 注册方式：
services.AddTransient<TService, TImplementation>();
特点：
- 当你需要服务在每个请求中创建一个新实例时，使用
Transient。 - 不共享实例，因此每次注入都会得到一个新的对象。
- 适合那些不保存状态的服务，比如某些业务逻辑操作、数据库查询等。
示例：
public void ConfigureServices(IServiceCollection services) { services.AddTransient<IMyService, MyService>(); }
使用场景：
- 无状态的服务或具有短生命周期的服务（例如，服务在每次调用时进行独立处理，并不需要维护任何持久化数据）。
2. Scoped（作用域）
- 生命周期： 在每个请求或作用域内创建一个服务实例，并且在同一个请求或作用域中共享该实例。
- 适用场景： 适用于需要在同一请求中共享实例的服务。典型场景是数据库上下文（
DbContext）等。 - 注册方式：
services.AddScoped<TService, TImplementation>();
特点：
- 在同一个 HTTP 请求或作用域中，共享同一个服务实例。
- 适用于服务依赖于请求上下文或作用域（如数据库事务或用户会话数据）的场景。
- 跨请求时会重新创建实例，但在同一个请求内不会重复创建实例。
示例：
public void ConfigureServices(IServiceCollection services) { services.AddScoped<IMyService, MyService>(); }
使用场景：
- 每个用户请求共享同一个实例，但不同的请求之间的实例是隔离的。
- 适用于数据库连接、用户请求处理等场景。
3. Singleton（单例）
- 生命周期： 在整个应用程序生命周期内只创建一个实例，所有请求共享同一个实例。
- 适用场景： 对象实例创建开销较大，或者需要在整个应用程序中共享数据或服务的场景。
- 注册方式：
services.AddSingleton<TService, TImplementation>();
特点：
- 在整个应用程序运行期间，服务只有一个实例。
- 适合跨请求共享数据，或者服务的实例化成本较高且不需要频繁变化的情况。
Singleton服务可能会在应用启动时就被创建，或者首次被请求时才会创建。
示例：
public void ConfigureServices(IServiceCollection services) { services.AddSingleton<IMyService, MyService>(); }
使用场景：
- 适用于跨多个请求需要共享数据的服务，如缓存、配置管理、日志记录等。
- 常用于应用启动时需要初始化的单例服务。
4. 总结比较
| 生命周期类型 | 服务实例的创建频率 | 生命周期说明 | 适用场景 |
|---|---|---|---|
| Transient | 每次请求时创建 | 每次依赖注入都会新建一个实例 | 无状态服务、轻量级服务 |
| Scoped | 在每个请求内共享 | 在一个请求的整个生命周期中使用同一个实例 | 数据库上下文、事务、用户请求上下文等 |
| Singleton | 整个应用程序生命周期内共享 | 在应用程序生命周期中共享同一个实例 | 配置管理、缓存、日志服务等 |
5. 使用场景举例
- Transient：数据库查询服务、HTTP客户端服务。
- Scoped ：
DbContext（通常每个请求使用一个数据库上下文）、身份验证服务。 - Singleton：应用配置、缓存、日志记录、缓存管理器。
通过合理选择服务生命周期模式，可以在保证应用性能的同时，更好地管理对象的状态和生命周期。
2. 依赖注入的优势
- 解耦合：通过依赖注入，一个类不再负责创建它所依赖的对象，而是将其依赖项传递给它。这样可以减少类之间的耦合。
- 易于测试：依赖注入让你更容易使用 mock 或 stub 替换服务，尤其在单元测试中，可以控制类的依赖项。
- 管理服务生命周期 ：你可以通过
Transient、Scoped和Singleton控制依赖的生命周期，确保在不同的请求和会话中管理资源的使用。 - 提高可维护性：依赖注入使得代码的组织和扩展更清晰，当系统需求变化时，你可以更方便地替换、扩展或重构服务。
- 灵活性：你可以灵活地替换服务实现，而不必更改类的内部实现，增强了系统的扩展性和适应性。
3. 常见的依赖注入错误
- 服务生命周期不匹配 ：比如，尝试将一个
Scoped服务注入到一个Singleton服务中，这样会导致容器无法创建该服务实例。 - 服务重复注册：同一个服务注册了多个实现，可能导致依赖注入容器混淆该使用哪个实现。
- 服务依赖过多：如果某个类依赖于过多的服务，可能表示该类的责任过重，应该考虑重构。